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

Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

blog.cloudflare.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#41

Post by skunkworker »

This seems to disregard some of the other factors that make Lambda > Cloudflare Workers. We run binaries on our lambda instance with a go-based function, since Lambda allows for up to 250mb of binaries, 3gb ram and 30s max, this allows us to perform computationally and ram heavy applications without worrying about our instance being killed off.

Also I looked into using cloudflare workers to write my own custom edge cdn but they currently don't allow you to change where in the call requests are processed or telling cloudflare what to cache vs not cache. If they could have some functionality that would allow you to easily write your own multi layered CDN this would be interesting.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#42

Post by jhgg »

For what it's worth at work (Discord) we serve our marketing page/app/etc... entirely from the edge using Cloudflare workers. We also have a non-trivial amount of logic that runs on the edge, such as locale detection to serve the correct pre-rendered sites, and more powerful developer only features, like "build overrides" that let us override the build artifacts served to the browser on a per-client basis.

This is really useful to test new features before they land in master and are deployed out - we actually have tooling that lets you specify a branch you want to try out, and you can quickly have your client pull built assets from that branch - and even share a link that someone can click on to test out their client on a certain build. Just the other week, we shipped some non-obvious bug, and I was able to bisect the troubled commit using our build override stuff.

The worker stuff is completely integrated into our CI pipeline, and on a usual day, we're pushing a bunch of worker updates to our different release channels. The backing-store for all assets and pre-rendered content sits in a multi-regional GCS bucket that the worker signs + proxies + caches requests to.

We build the worker's JS using webpack, and our CI toolchain snapshots each worker deploy, and allows us to roll back the worker to any point in time with ease.

I wrote probably the stupidest worker script too, that streams a clock to your browser using chunked requests: https://jake.lol/clock (no javascript required).

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#43

Post by Matthias247 »

kentonv wrote: post #22
poulpi wrote: post #4

Have you think about including Golang based Lambda function in your benchmark? As you're guessing that Cloudfare superior JS runtime plays a big role, it could be interesting to see if it can compete against Golang Lambda as well.

A lot of our performance benefit comes from lighter-weight sandboxing using V8 instead of containers, which makes it feasible for us to run Workers across more machines and more locations. It wouldn't surprise me too much if a Worker written in JS can out-perform a Lambda written in Go, as long as the logic is fairly simple. But I agree we should actually run some tests and put up numbers... :) On another note, curre…

Just curious: The article mentions V8 isolates. Do you actually also run all IO of the worker in the same isolate? Or in a different one, and the API calls are bridged (via some webworker-like API)?

I guess one of the main challenges is that all resources are properly released when a worker is shut down. Releasing memory sounds pretty easy, if V8 does it for you. But releasing all IO resources might be a bit harder, especially if they are shared between isolates.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#44

Post by mayank »

1996 wrote: post #36
greenail wrote: post #32

Earlier quoted context omitted.

The lockin argument alone is a red herring. Every technology implementation creates lockin. The valid question is how hard is something to change. A good architecture balances how easy it is to change something with how optimized it is, also balancing how much it costs to build and maintain. Realistically you can get as locked into Amazon as you want, lambda alone does not create inescapable lockin by any measure so…

Amazon performance is generally bad when using other services. We are rolling out a CDN, with a goal of 20 ms latency in most countries. We want more granularity that AWS - and some zones are just not well served (No AWS in Africa, incomplete offer in Brasil, etc) Still, we figured we would use Route 53 as you can do Latency Based Routing even with non-AWS servers. Computing latency or using EDNS0 as a proxy is not r…

Saying Route53 takes “2 seconds” to resolve is pretty meaningless without a distribution or at least percentiles. Route53 obviously doesn’t take 2 seconds for all or most queries.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#45

Post by mayank »

zackbloom wrote: post #9
kevan wrote: post #8

>To be fair, comparing my Lambda, which only runs in us-east-1 (Northern Virginia, USA), to a global service like Workers is a a little unfair. At least you acknowledge that it's a bit silly to use a global benchmark to compare a global service with an intentionally-regionalized service.

Why would you run something in a single location if you can run it everywhere for the same price though? It's not like Lambda is cheaper for being centralized.

If your function is IO heavy and your datastore isn’t globalized (as most aren’t, save Spanner and its ilk), you may prefer your function running in the same region as your data to minimize DB latency and transfer cost.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#46

Post by mayank »

zackbloom wrote: post #29
mchahn wrote: post #26

> The functions being tested simply return the current time Not a very interesting benchmark. This would only measure net latency and spin-up time.

I have a post which should come out later in the week which dives into the performance with CPU-intensive workloads. tl;dr is that a 128MB Lambda is about 8x slower than a Worker.

Can you also throw in some adversarial workloads? Simple proof of work using node’s builtin crypto module would be a nice benchmark for V8 isolates vs Lambda’s processes, and would go a long way convincing people that using isolates is reliable in a shared setting relative to processes/containers.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#47

Post by jbergstroem »

I'm using cloudflare workers to "polyfill" client hints if they're missing with cookie logic. With their addition of being able to mutate cache keys via edge workers I find it to be a extremely powerful way of everything from per-device image optimization (or google data saver or hidpi support) to serving different pages for the same uri based on your requirements (and storing this in cache).

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#48

Post by 1996 »

mayank wrote: post #44
1996 wrote: post #36

Earlier quoted context omitted.

Amazon performance is generally bad when using other services. We are rolling out a CDN, with a goal of 20 ms latency in most countries. We want more granularity that AWS - and some zones are just not well served (No AWS in Africa, incomplete offer in Brasil, etc) Still, we figured we would use Route 53 as you can do Latency Based Routing even with non-AWS servers. Computing latency or using EDNS0 as a proxy is not r…

Saying Route53 takes “2 seconds” to resolve is pretty meaningless without a distribution or at least percentiles. Route53 obviously doesn’t take 2 seconds for all or most queries.

I am quoting the author, and their analysis of the initial query. This observation from whoever wrote the article matches my own experimental results: initial queries are very very slow on Route 53 LBR. A distribution of queries is useless and misleading, as later queries are cached if you have a sufficient TTL - so only the first few really matters in the performance results.

Later queries are fast of course, as the results are cached (TTL).

Even if the DNS is very pooly configured, all queries after the first one will benefit from the cache!! So the first few queries matter much more, and this is what we should be talking about instead of distributions and percentiless.

Said differently: If each of your visitor has to way a second or two until the site comes up the first time, then the site works normally, it may still give them a bad impression.

I measured the DNS delay on first Route53 reply to be over 700 ms personally. For the author it is 2000 ms. These results are in the same order of magnitude, and make Route53 unsuitable for many applications. Of coutse, you could start hacking, like keeping Amazon cache warm by issuing queries through chron, or by setting extremely long TTLs and hoping your visitors DSL modem will keep your A records in cache as long as you asked for - but these are just hacks trying to compensate that the first DNS query takes SECONDS to process.

Route53 LBR DNS is not as a "slow and requiring hacks". It's supposed to be fast, simple to run, and to ingrate with different ecosystems. To me, it seems to be none of that.

After assessing Route53 as fubar, I switched from AWS to Azure: TrafficManager offers the same features, and the first request takes less than 350ms. There must still be some cruft in there, but at least it is manageable.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#49

Post by xstartup »

I was working on an app which serves roughly 400*10^6 API requests/day.

One cool property of our app is that it's rarely updated and mostly read.

And the goal is to achieve the lowest possible latency at the edge.

It scales beautiful, I am not sure which other architecture can help us keep this afloat with only 4 developers working on it.

So, we have a DynamoDB table which is replicated to multiple regions using DynamoDB streams and Lambda.

For us, Lambda means achieving a lot without many developers and system administrators but I understand that not all problems yield gracefully to this pattern.

It seems using Cloudflare Workers to trigger our Lambda function instead of API gateway could prove to be cheaper.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#50

Post by zackbloom »

xstartup wrote: post #49

I was working on an app which serves roughly 400*10^6 API requests/day. One cool property of our app is that it's rarely updated and mostly read. And the goal is to achieve the lowest possible latency at the edge. It scales beautiful, I am not sure which other architecture can help us keep this afloat with only 4 developers working on it. So, we have a DynamoDB table which is replicated to multiple regions using Dyna…

Would it be possible to read the data through the Cloudflare cache? If so your data and API would be replicated not just around the world but actually within the majority of the worlds ISPs. Based on our experiences with 1.1.1.1, Cloudflare is within 20ms roundtrip of most people on earth.
Post reply on HN