Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unpacking Cloudflare Workers CPU Performance Benchmarks

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#71

Post by misiek08 »

l5870uoo9y wrote: post #33

I am in the process of porting my web app[1] from NextJS hosted at Vercel to Astro/React hosted at Cloudflare, and something that particularly surprises me is that I can render a web app on every request at “the edge” and have response times of 100-200ms. That is almost as fast as fully static pages. I have also definitely noticed an improvement in Cloudflare Worker over the last few weeks; cold starts have practical…

C'mon - static pages are like 10ms or less. 200ms is already noticeable, not-instant for humans. We have 5-10x faster hardware and 10x slower websites ;)

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#73

Post by NicoJuicy »

TiredOfLife wrote: post #44
aperture147 wrote: post #34

It’s good that CF is actually trying to improve its platform instead of blaming others for smearing its product. Still, the breakneck pace is a mixed blessing. Things change so fast it’s hard to keep up, and launches often outrun polish. The R2 Data Catalog still lacks Iceberg v3 support; Wrangler has shifted dramatically in just a few months; and Pages seems to be on the way out, leaving me with Workers Assets that…

Fun thing is that this started because somebody claimed that Cloudflare is faster than Vercel. Then somebody who knows what they are doing did benchmarks that showed the opposite. And then worked with Cloudflare to make it faster

And nobody on the benchmarks mentioned that Vercel runs it on 2 gb. Instances ( and much more expensive) while Cloudflare is competitive with 128 mb. instances.

I guess that's the difference between building on top of AWS and actually building your own infrastructure.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#74

Post by graycat »

For garbage collection and the idea of assigning storage requests to different categories of (dynamic) storage ....

Apparently part of the algorithm is based on the size of the storage being requested.

Hmm. So, we have historical data of storage requests and for each (i) the size of the request, (ii) how long until the storage is freed, (iii) etc. ....

Guessing about a bizarre case: It might be that on Monday many storage requests of certain small sizes have lifetime just a little longer than the decision to move the request to another category, i.e., the moving effort was inefficient, wasted.

So, in simple terms, for an optimization, for each of the variables have both in the history and real time, make the variable values discrete, altogether may have for some positive integer n a few thousand different n-tuples of variable values; then for each n-tuple pick the best decisions (policies, etc.). Uh, unless this idea has already been tried.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#75

Post by noir_lord »

ErikCorry wrote: post #57
jrpelkonen wrote: post #56

Great 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 corr…

Not silly at all - with such a massive surface even specialists on a part of it don't see all of their part all of the time :).

Any dev who's been around a while has been bitten by many assumptions or straight blindspots many times.

"Huh..that's weird" has been the entry point to some truly astounding ones over the years for me at least.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#77

Post by sema4hacker »

pyrolistical wrote: post #15

This is why we need competition and independent benchmarks. This shames poor performing product/service into action.

Yes, competition is good and mergers and acquisitions are bad. It also shows why you always have to internally be comparing yourself to the competition and not be complacent, before someone independently does the comparison for you and you're embarrassingly caught with your pants down.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#78

Post by l5870uoo9y »

lukecarr wrote: post #42
l5870uoo9y wrote: post #39

Earlier quoted context omitted.

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…

Have you given Hyperdrive[0] a try? In theory, it should improve performance in your use case where you have a central database (Railway) being connected to from the Edge (your Workers). It moves the DB connection logic closer to your Workers, pools connections, and can also cache queries. (Disclaimer: I work for Cloudflare, but on an unrelated team. Not personally used Hyperdrive, but heard good things!) [0]: https:…

It actually looks very interesting, but my app is not particularly affected by database query time, but rather by the time spent on the various AI generations.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#79

Post by l5870uoo9y »

pjc50 wrote: post #41
l5870uoo9y wrote: post #39

Earlier quoted context omitted.

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…

So a remote, authenticated DB connection over the internet? How many db queries per page generation does that generally work out as?

My app isn't database heavy; most pages renders without a single database call (user information stored in cookie) and the pages that do call the database contain maximum one call. Other data, like database schemas and subscription status, are requested in the background directly from the browser so it doesn't stall page rendering.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#80

Post by aperture147 »

TiredOfLife wrote: post #44
aperture147 wrote: post #34

It’s good that CF is actually trying to improve its platform instead of blaming others for smearing its product. Still, the breakneck pace is a mixed blessing. Things change so fast it’s hard to keep up, and launches often outrun polish. The R2 Data Catalog still lacks Iceberg v3 support; Wrangler has shifted dramatically in just a few months; and Pages seems to be on the way out, leaving me with Workers Assets that…

Fun thing is that this started because somebody claimed that Cloudflare is faster than Vercel. Then somebody who knows what they are doing did benchmarks that showed the opposite. And then worked with Cloudflare to make it faster

They might flip the emergency switch that burns a little more money to improve the cold start, schedule more CPUs to each V8 process or remove the `sleep(100)` somewhere in the code. I kinda doubt that they have actually made any code improvement but just a marketing stunt that make everything seems to be faster for a month then everything will be just as slow as it is, or they are buying time to actually improve the code.
Post reply on HN