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

41–50 of 80 posts

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#41

Post by pjc50 »

l5870uoo9y wrote: post #39
steelbrain wrote: post #37

Earlier 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…

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

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#42

Post by lukecarr »

l5870uoo9y wrote: post #39
steelbrain wrote: post #37

Earlier 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…

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://developers.cloudflare.com/hyperdrive/

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#43

Post by sofixa »

itake wrote: post #35
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…

Where do you see that "pages seems to be on the way out"? I use pages for a few projects...

The migration guide contains this:

> Workers will receive the focus of Cloudflare's development efforts going forwards, so we therefore are recommending using Cloudflare Workers over Cloudflare Pages for any new projects

https://developers.cloudflare.com/workers/static-assets/migr...

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#44

Post by TiredOfLife »

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

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#45

Post by csomar »

itake wrote: post #35
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…

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.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#46

Post by mb2100 »

FlyingSnake wrote: post #26
hu3 wrote: post #17

My take from this article is that SvelteKit is crazy fast and Next.js is a snail

I hope a pragmatic framework like SvelteKit, Astro or TanStack replace NextJS complexity vendors soon.

Indeed. Would you consider https://mastrojs.github.io a "pragmatic framework"?

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#47

Post by kelvinjps10 »

csomar wrote: post #45
itake wrote: post #35

Earlier 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.

It's hard if you don't use a JavaScript based SSG, well I didn't find how to do it with Hugo so I'll stay in cloudfare pages

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#48

Post by refulgentis »

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

Theo knowing what he’s doing died for me when he did a dive into this fancy new data format OpenAI started using to stream responses from the server and how wasteful it is (SSE) (and this was in 2025)

I don’t except everyone to know everything but it made me very careful about differentiating Theo-the-engineer from Theo-the-social-media-dude.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#49

Post by csomar »

kelvinjps10 wrote: post #47
csomar wrote: post #45

Earlier quoted context omitted.

I didn't find it hard to migrate. Pages are workers, so might as well just use a worker.

It's hard if you don't use a JavaScript based SSG, well I didn't find how to do it with Hugo so I'll stay in cloudfare pages

Generate the files locally and then push them to the worker? Even with a JS based SSG that's the only way to do it and the difference between worker and pages. (workers have no build step)

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#50

Post by rajeevk »

pjc50 wrote: post #40
aperture147 wrote: post #36

Earlier quoted context omitted.

CF used to encouraged people to move to Workers instead of using Pages. They recently removed the message in their landing page that said so (just checked, you could visit Wayback Machine to verify), so I guess Pages will still be available anyway. Btw the best thing that Pages gives out is allowing people to use different domain from another domain registry when Workers force user move their domain to CF.

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)
Post reply on HN