Live data from Hacker News

Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

openstatus.dev

11–20 of 43 posts

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#13

I wonder how much the open status server allocation plays a role in this case - they tested from 6 different location but its not clear if fpr example openstatus servers are in closer datacenters.

> We use Fly.io in production and are satisfied with it.

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#14
post #6

I feel like this title is misleading compared to the original article. (cc @dang) Fly.io without cold starts (which is a one-line configuration change) is 2x faster than Cloudflare Workers.

Ok, we've changed to the article's title now, in keeping with the HN guidelines: https://news.ycombinator.com/newsguidelines.html. (Submitted title was "Hono on Cloudflare Workers is 3x faster than alternatives")

Submitters: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#16
I was surprised to see such miserable measured latency to Fly, but then I saw this note:

>The primary region of our server is Amsterdam, and the fly instances is getting paused after a period of inactivity.

After they configured Fly to run nonstop, it outperformed everyone by 3x. But it seems like they're running the measurement from Fly's infrastructure, which biases the results in Fly's favor.

Also weird that they report p75, p90, p95, p99, but not median.

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#17
OP's note about Johannesburg's latency is something I've noticed over the past few weeks in particular. Our servers are hosted in South Africa, yet accessing most of our sites and services from within South Africa causes traffic to be re-routed via other nodes, mostly London (LHR). This is easy to verify by appending cdn-cgi/trace onto a Cloudflare-proxied domain.

Something is definitely up with Cloudflare's Johannesburg data centre. On particularly bad days, TTFB routinely reaches 1-3 seconds. Bypassing Cloudflare immediately drops this to sub 100ms.

In the past, I would have emailed support@cloudflare.com, but it seems that this channel is no longer available for free tier users. What is the recommended approach these days for reporting issues such as this?

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#18

Very odd that AWS Lambda/Google Cloud Functions weren't tested. Those CF numbers are impressive though, they beat Lambda cold start by a mile.

They always will; starting an Isolate in v8 will always beat a Docker or VM start. They only work with Javascript, but if you're okay with that, then you will have tiny cold start times.

Re: Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render

#19
im curious what the results would be with a more production-like app

e.g. if you add prisma connecting to postgres, presumably there's extra latency to create the client. for the fly app, you have a server reusing the client while it's warm. presumably for the cloudflare worker, you're recreating the client per request, but im not 100% on that. how would the latency change then for cold vs warm, and on the other platforms?

Post reply on HN