Nice bit of subtle shade here:
> we chose instead to run our test client directly in AWS's us-east-1 datacenter, invoking Vercel instances running in its iad1 region (which we understand to be in the same building).
Unpacking Cloudflare Workers CPU Performance Benchmarks
51–60 of 80 posts
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#52Earlier quoted context omitted.
Hello! How are you collecting your edge workload to the database? Are you using cloudflare’s database? I’ve wanted to try out this edge hosting thing but because of the amount of round trips involved between the application and the database, the application performs worse on the edge. Thanks!
The database is hosted on Railway. I have enabled Smart Placement that should, depending on request time, automatically use an endpoint closer to the database to speed it up. When requesting a route that includes a database request, the response time on the US east coast is around 200ms and closer to 1000ms in Denmark. I am hoping that the Smart Placement will work better when I go live with the app (still in beta) a…
[deleted]
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#53This is great PR. Well done to whoever orchestrated that post.
To give a take from a happy cf customer – not only do they have a great engineering culture when it comes to writing blog posts and OSS but also the best customer service of any infra company I've ever used.
The team, including kenton who wrote this post, are often available on discord to provide help and take in feedback about cf products, if you find a bug or have a problem you can often be talking directly to the engineer who looks after that product. I've made PRs and feature suggestions on cloudflare products that got accepted without much hassle / protocol
Don't mean to put down others, but I receive better support from cf on an extremely small monthly bill (the free tier is too good) than I have got from a certain massive company's account managers on six figures a month bills.
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#54Earlier quoted context omitted.
Where do you see that "pages seems to be on the way out"? I use pages for a few projects...
I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.
Just to note because I was confused by this:
I was under the impression that workers are just lambda functions, and therefore would fall under different billing rules than pages which serve static files (with unlimited bandwidth).
But workers apparently have a 'Static Assets' feature that just serves static assets (like pages) and comes with free unlimited requests, unlike worker function invocations, so as you say it seems to be essentially the same as pages.
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#55Earlier quoted context omitted.
I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.
Just to note because I was confused by this: I was under the impression that workers are just lambda functions, and therefore would fall under different billing rules than pages which serve static files (with unlimited bandwidth). But workers apparently have a 'Static Assets' feature that just serves static assets (like pages) and comes with free unlimited requests, unlike worker function invocations, so as you say i…
What I meant the same as worker, is that under the hood, pages are just workers. The Static Assets feature was probably added because the by-request billing wouldn't make any sense for static assets.
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#56Great write up, focusing on facts without fingerpointing.
But I must admit I was somewhat surprised Cloudflare was not already proactively monitoring and tuning the generation sizes. Configuring the generation sizes was table stakes for JVM performance tuning back in the day.
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#57Great write up, focusing on facts without fingerpointing. But I must admit I was somewhat surprised Cloudflare was not already proactively monitoring and tuning the generation sizes. Configuring the generation sizes was table stakes for JVM performance tuning back in the day.
We choose to be transparent when we fix stuff, even if it makes us look a bit silly :-) . We are certainly installing more logging and tracking of this sort of thing!
In general I think the GC should auto-adapt as much as possible. It's a bit of an admission of defeat for the GC author if the users have to spend a lot of time tuning the parameters. What we are doing here is removing the tuning that was no longer correct, and allowing V8 more latitude to pick its own young gen size.
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#58Grab the popcorn, the Vercel v Cloudflare drama unfolds
competition is how customers get better products
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#59It's pretty crazy how some video by a relatively small content creator snowballed into Cloudflare making meaningful changes and addressing platform issues
Re: Unpacking Cloudflare Workers CPU Performance Benchmarks
#60Earlier quoted context omitted.
Workers require you to use CF as a domain registry? Where is that written and what possible reason do they give for it? That's quite an imposition.
Not the domain registry but CF wants to manage the DNS to make it work. If you do not want them to manage your DNS and want to work by simply pointing your CNAME, they ask you start with their business plan ($250 / per month)
Right, but that's not the same thing and is intrinsic to how CF works - routing DNS requests from different areas to different IPs. Is there any good reason not to just let them serve your DNS if they're serving your website?
(will they accept a delegated subdomain?)