-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vercel Proxying: add config to test proxying #1957
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
We'd like to try experimenting with pointing www.ifixit.com at vercel and have vercel proxy any missed routes to our main php app. Before we make changes at the CDN level, let's set up this rewrite to do some experimentation.
2ca6901
to
7c515dc
Compare
We'd like to test the performance (and features) of proxying through our proxylb. So, let's add a few more fallback routes. I'm also not sure if query strings get forwarded in this proxying setup, so this also allows for testing of that. /health-check is a fast-responding endpoint in apache that always returns a 200 from the app machines.
deploy_block 👍 We don't exactly need to merge this in order to test it, so let's hold off. |
@davidrans and I did a bunch of experimenting and benchmarking. We used the Here's what we learned from the places we tested:
Note: all these tests were done with The short of it is that vercel -> proxylbs -> php-app looks like a reasonable option and was very easy to configure. If it's not too hard, I'd like to test proxying from within the main next.js process. Thinking that vercel has optimized the Edge -> Washington DC route and hopefully keeps connections alive. |
Do you mean by adding a catch all route? |
I'm open to any way that can test it out. The little research I didn't on using a middleware to do it indicated the middleware would also run on the edge. If you've got a solution in mind, feel free to push a commit here. I'd love to experiment with performance on that option. |
📦 Next.js Bundle Analysis for @ifixit/commerce-frontendThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
Note: unfortunately, you can't use: return NextResponse.rewrite(...) here, otherwise you get an error like: [Next] - error Error: API route returned a Response object in the Node.js runtime, this is not supported. Please use `runtime: "edge"` instead: https://nextjs.org/docs/api-routes/edge-api-routes Which is precisely what we *don't* want.
7ec1c33
to
c70c72d
Compare
CR ⚡ dev_block ⚡ on a potential version mismatch but otherwise this looks like a reasonable test. |
Yes, we're using a newer lib version than the types we have... but I'd rather not downgrade to an older version and we use so few features.
Updated Numbers (with new proxy option)
|
To be clear, we don't need to merge this to test it. We've been testing the |
This prevents next.js from warning about unhandled requests. > externalResolver is an explicit flag that tells the server that this > route is being handled by an external resolver like express or connect. > Enabling this option disables warnings for unresolved requests.
6aa4047
to
74b21cc
Compare
74b21cc
to
5d8df46
Compare
5d8df46
to
adc376d
Compare
adc376d
to
07e2177
Compare
I've got a spreadsheet going but I forgot one more proxy to monitor (the current CF -> proxylbs) one. I've added it and am awaiting the numbers. |
These are the numbers thus far, all times are in ms Performance
CostsI've looked at some graphs and it seems we use about 250ksec of request time on the php app per day. This amounts to approximately: We also use about ~80GB per day of bandwidth which would cost: Unless we sign up for the enterprise plan... which could be more or less expensive. |
Thanks for doing this work, very interesting insights @danielbeardsley !
Maybe by leveraging the CDN cache a bit more there's room for reducing costs, but I definitely agree that bandwidth costs are not cheap. 😬 If there's appetite for saving on infra costs, we can also skip the intermediary and go directly to the source: https://pages.cloudflare.com/ |
The costs would actually be somewhat lower in practice. Here's an annotated estimation: Current Cloudfront Bytes per day (includes proxied vercel traffic): 84GB Total Bytes per day that would be moved from CF to vercel: 69GB We are only using ~500GB/month of our current 1TB / month vercel bandwidth Current Cloudfront cost for the bytes in question is $126
So, an additional $500 per month. Probably worth talking to Vercel and asking about enterprise deals. Buuuut, we don't want to get hoodwinked into paying a higher price per GB than the current on-demand rates. |
Here is an updated and easier to interpret performance chart. I've also added a line ( Difference from current (Cloudfront -> Proxylbs) performance:
|
The research is done here, we've learned the lessons; I'm gonna freeze this. |
This can be re-opened (if desired) in this code's new home |
We'd like to try experimenting with pointing www.ifixit.com at vercel and have vercel proxy any missed routes to our main php app.
Before we make changes at the CDN level, let's set up this rewrite to do some experimentation.
Note: this proxies to a domain that is configured here: https://github.com/iFixit/ifixit/pull/49636
Connect #1884