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

61–70 of 80 posts

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#61

Post by jonathanlydall »

pjc50 wrote: post #60
rajeevk wrote: post #50

Earlier quoted context omitted.

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?)

They don't accept delegated subdomains, at least not for .net and .com domains (I haven't tried others).

I don't see how it's "intrinsic to how CF works" that they need to host your DNS records, especially when they don't require it on more expensive plans.

That being said, I don't mind them hosting my DNS records, but it would have been nice if they supported importing zone files from Azure DNS.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#63

Post by kordlessagain »

weird-eye-issue wrote: post #16
orliesaurus wrote: post #12

cf has to hire people with obsession not benchwarmers that only activate when someone yells at them because of a twitter argument. there i said it. vercel only exists because cf got lazy. huge fan of CF, and if cloudflare had the attention to details that vercel has, there would be no vercel. fullstop. CFs docs, repos, video content but also code samples, sdks (lol all the mcp stuff) usually is subpar to vercel's. it…

CF isn't lazy at all. Their docs often aren't that great but it's because they seem to be prioritizing launching new products and features

Right. Cloudflare is an authorized man in the middle attack.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#64

Post by jrpelkonen »

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…

I appreciate the candor, and I agree that auto-adaptation probably makes sense in this use case because the workloads are unknown and varied.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#65

Post by kentonv »

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…

> Configs that worked in Wrangler 3 didn’t carry over cleanly to Wrangler 4, and it feels like Wrangler 5 will introduce yet another interaction model.

There were no changes to the config format in Wrangler 4. The reasons for the major version bump didn't affect 99.99% of users. They are listed here:

https://developers.cloudflare.com/workers/wrangler/migration...

Personally I pushed back on bumping the major version at all, because I know even a no-op major version update creates pain. But the team wasn't comfortable given the obscure edge cases. We have resolved, though, that in the future we'll build ways to manage all these issues without requiring a major version bump (e.g. support multiple versions of esbuild, so that you can upgrade wrangler without updating esbuild).

Incidentally, on the runtime side especially, we're pretty maniacal about backwards compatibility: https://blog.cloudflare.com/backwards-compatibility-in-cloud...

> Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.

Pages are not "on the way out". Workers Assets are just a new, more flexible implementation of Pages, which makes it easier to use other Workers features together with Pages. If you don't need those other features, you do not need to migrate. Eventually, we will get to the point where we can auto-migrate everybody, we just aren't there yet.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#66

Post by troyvit »

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…

> and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate.

According to this community post CF isn't going to deprecate pages until workers achieve parity: https://community.cloudflare.com/t/static-web-site-in-worker...

That said I can't actually find a place where CF says pages are deprecated. pages.cloudflare.com seems all-in on it, as does developer.cloudflare.com/pages. I see a reddit post where somebody implies they're deprecating pages, but the page they link to [1] doesn't mention anything about pages going away.

That doesn't take away from the rest of what you're saying, it's just the part that made my heart skip a beat.

[1] https://www.reddit.com/r/webdev/comments/1mme85y/cloudflare_...

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#67

Post by kentonv »

troyvit wrote: post #66
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…

> and Pages seems to be on the way out, leaving me with Workers Assets that are painful to migrate. According to this community post CF isn't going to deprecate pages until workers achieve parity: https://community.cloudflare.com/t/static-web-site-in-worker... That said I can't actually find a place where CF says pages are deprecated. pages.cloudflare.com seems all-in on it, as does developer.cloudflare.com/pages. I…

It's not deprecated. There's confusion because the implementation is changing to be better-integrated with Workers, and currently it's manual migration to get the new implementation, but eventually it'll be automatic. It'll still be called "Pages" when that happens.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#68

Post by yomismoaqui »

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…

Reminder to use boring tech when building something important that should last for some years.

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#69

Post by brycewray »

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

https://gohugo.io/host-and-deploy/host-on-cloudflare/

https://discourse.gohugo.io/t/hugo-support-in-cloudflare-wor...

https://discourse.gohugo.io/t/hosting-a-hugo-site-on-a-cloud...

Re: Unpacking Cloudflare Workers CPU Performance Benchmarks

#70

Post by jokethrowaway »

orliesaurus wrote: post #12

cf has to hire people with obsession not benchwarmers that only activate when someone yells at them because of a twitter argument. there i said it. vercel only exists because cf got lazy. huge fan of CF, and if cloudflare had the attention to details that vercel has, there would be no vercel. fullstop. CFs docs, repos, video content but also code samples, sdks (lol all the mcp stuff) usually is subpar to vercel's. it…

CF has strong tech core but some products are unusable.

You can see CF Pages had barely zero resources and the product got worse over time.

Lots of issues shipping examples from mainstream frameworks that work flawlessly on vercel, netlify or github pages. Now they removed support for something and I can't ship half of my "legacy apps". I ship everything on Kubernetes and just cache it with free cloudflare.

It can also be a strategy: they don't care about freeloaders devs shipping another app, they want the enterprise business.

Post reply on HN