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

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

openstatus.dev

Post reply on HN
Print view View original

31–40 of 43 posts

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

#31

Post by catlifeonmars »

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

I’m not sure what’s customary in most places, but in my experience you base most things off of avg and p99 and then you can use other percentiles to interpolate the shape of the distribution in the event you need a better model (you usually don’t). Of course I’m sure this sort of thing varies wildly by use case.

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

#32

Post by reissbaker »

byyll wrote: post #25
mxstbr wrote: 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.

Isn't the whole point to not have a constant function running and waiting?

I think it depends on your use case. If you want serverless — well, yes! You want it to scale down to zero and scale up to infinity really fast. Cloudflare Workers are really good at that.

On the other hand, if you want lowest possible latency, and the ability to run normal Linux applications (rather than being confined to the Cloudflare Worker limits, e.g. maximum worker size is 10MB), something like Fly.io is pretty nice: it's even lower latency than Cloudflare assuming you keep the machines running, and scaling up/down is relatively quick although not something you'd generally be doing every few seconds.

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

#33

Post by jshier »

richardkeller wrote: post #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 Johannes…

Only remaining support channel is their community forums. Whether you'll get an official response is another question.

I don't recall Cloudflare routing request to their free clients differently than paid, but I've read multiple reports of that happening recently. Change in policy or fallout from something else?

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

#34

Post by foofie »

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

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

I'm not aware of P50s having ever been a relevant performance metric in latency. The focus of these latency measurements were always the expected value for most customers, and that means P90-ish.

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

#35

Post by foofie »

robertlagrant wrote: post #18
joshstrange wrote: post #3

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.

> They always will; starting an Isolate in v8 will always beat a Docker or VM start.

Is that the case though? AWS is upfront in how their nodejs lambdas being the preferred choice for low overhead, low latency, millisecond workloads, and as they also control the runtime I'd be surprised if they followed the naive path you're implying of just running nodejs instances in a dumb VM.

Hell, didn't AWS just updated the way they handled JVM lambdas to basically not charge for their preemptive starts and thus make them look as performant as nodejs ones?

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

#36

Post by bishopsmother »

jshier wrote: post #33
richardkeller wrote: post #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 Johannes…

Only remaining support channel is their community forums. Whether you'll get an official response is another question. I don't recall Cloudflare routing request to their free clients differently than paid, but I've read multiple reports of that happening recently. Change in policy or fallout from something else?

An example community forum query, albeit from 2021, regarding Periodic Cloudflare Worker datacenter allocation issues: https://community.cloudflare.com/t/periodic-cloudflare-worke... . In summary: no official response/conclusion.

Users in the UK having their traffic sent to Australian Cloudflare DC Workers was quite the round-trip/tromboning-a-go-go...

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

#37

Post by cheviethai123 »

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

Using median to report latency is very weird. I haven't seen any tech report using median though and curious to see one, can you provide?

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

#38

Post by tibozaurus »

anurag wrote: post #20

(Render CEO) Our free services are meant for personal hobby projects that don't need to stay up all the time; I'd love to see tests (and uptime monitoring) for the $7/mo server on Render. Happy to give you credits if it helps.

Sure I would love that!

But it's not all about latency a real world application will be different for sure !

send us an email at ping@openstatus.dev :)

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

#39

Post by tibozaurus »

catlifeonmars wrote: post #30

Those Fly.io p99 latencies are atrocious. 2.6s P99 compared to CloudFlare 1.0s. Neither one seems particularly great at first glance, but the CloudFlare worker latency does seem on par with Lambda from previous experience (I have not tested Lambda@Edge or CloudFront Functions).

It's due to cold start on default preset when creating an app if you are running the app continuously it's good

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

#40

Post by richardkeller »

Havoc wrote: post #28
richardkeller wrote: post #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 Johannes…

I’ve seen this a couple times before not just CF but other ISP too. Must be something funky with peering politics in SA perhaps

From the bit of digging that I've done, it's all free tier domains that are affected. Paid tiers are not affected by this. Given that I've tested from multiple different ISPs, I think this is the fault of Cloudflare intentionally de-prioritising free tier traffic, rather than an issue with local routing.
Post reply on HN