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

51–60 of 65 posts

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#51

Post by zackbloom »

skunkworker wrote: post #41

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

It’s worth pointing out Amazon charges more than 10x a Worker on a per execution basis to use it as you describe for just 100ms of compute. If you’re actually using 30s it’s probably very expensive indeed.

The statements in the second paragraph are fortunately incorrect. With the exception of some security features Workers totally takes over the incoming request. It can use flags in its subrequests to configure the cache as you need, and will soon have access to the raw Cache API.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#52

Post by zackbloom »

iamleppert wrote: post #40

This really isn't a very good benchmark. It's basically only validating the Cloudflare edge network, but the test itself is far from real-world. A service that returns the current time is not doing anything practical and borders on meaningless.

We have a post which compares CPU intensive workloads which should be ready after the American holiday. The summary is a 128MB lambda provides you with roughly 1/8 of a CPU core, which is therefore 8x slower than a worker.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#53

Post by zackbloom »

mayank wrote: post #46
zackbloom wrote: post #29

Earlier quoted context omitted.

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.

Can you elaborate on this? How would doing crypto demonstrate the security of the isolate?

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#54

Post by zackbloom »

cordite wrote: post #39

“Half a decade of experience” doesn’t sound like much these days.

That’s fair, the truth is some of the people here have been around since the beginning of the internet, so four decades might be more fair. Unless you add up everyone’s experience, then we’re in the millennia...

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#55

Post by mayank »

zackbloom wrote: post #53
mayank wrote: post #46

Earlier quoted context omitted.

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.

Can you elaborate on this? How would doing crypto demonstrate the security of the isolate?

Nail the CPU and ensure that other isolates on the same process/machine don’t get starved. I meant isolation more than security.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#56

Post by kentonv »

jhgg wrote: post #42

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

At Cloudflare we're all in awe at how fast https://discordapp.com loads... nice work.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#57

Post by kentonv »

1996 wrote: post #37
kentonv wrote: post #17

As the architect of Workers I was obviously pretty happy with Zack's results in general. But, I'm not happy with the tail latency (99th percentile), even if it beats the competition. I suspect this has to do with GC pauses. The solution may be to proactively run GC in a background thread between requests. For high-traffic workers that are always processing requests, we could load multiple instances of the worker and…

You are from Cloudflare? Could you tell me why the replies to geoip/latency based routing CNAMEs do not seem to be cached by Cloudflare? The setup is: domain.com -> geoiplbr.domain.com with cloudflare caching enabled. Nothing else that is fancy and could cause delays. If I measure the TTFB for domain.com, I see a large DNS delay until about the 4th consecutive query - and then the DNS is no longer the limiting factor…

Sorry, I work on Workers, not DNS, so I honestly don't know.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#58

Post by kentonv »

mayank wrote: post #55
zackbloom wrote: post #53

Earlier quoted context omitted.

Can you elaborate on this? How would doing crypto demonstrate the security of the isolate?

Nail the CPU and ensure that other isolates on the same process/machine don’t get starved. I meant isolation more than security.

Different isolates can run concurrently on different threads, so pegging the CPU in one isolate doesn't block any others. Also, if a worker spends more than 50ms of CPU time on a request, we cancel it, terminating execution of the worker even if it's in an infinite loop. (Almost all non-buggy Workers we've seen in practice use more like 0ms-2ms per request. Note this is CPU time; time spent waiting for network replies doesn't count.)

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#59

Post by kentonv »

Matthias247 wrote: post #43
kentonv wrote: post #22

Earlier quoted context omitted.

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

The Workers runtime itself is implemented in (modern) C++, not JavaScript. So, there's no need for a separate isolate -- API objects are implemented directly in C++.

In C++, memory and I/O resources are both managed through RAII. Of course, when binding to JavaScript, we often end up at the mercy of the JavaScript GC to let us know when an object is no longer reachable from JS, and the GC makes no promises as to how promptly it will notice this (maybe never). That's fine for memory (it amortizes out) but not for I/O resources. So we're back at the original problem.

Luckily, in the CF Workers environment, it turns out that all I/O objects are request-scoped. So, once a request/response completes, we can proactively release all I/O object handles bound into JS during that request/response. If JS is still holding on to those handles and calls them later, it gets an exception.

Post reply on HN