Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge • Hacker News Board

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#61

Post by adreamingsoul » Tue, Jul 03, 2018, 5:35 PM UTC

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…

I haven't dug too deep into this, but when loading view-source:https://jake.lol/clock I'm seeing on average 14 second load times. Does this happen for anyone else?

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#62

Post by jhgg » Tue, Jul 03, 2018, 6:12 PM UTC

kentonv wrote: post #56

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.

Thanks! And thanks for building Cloudflare workers. You have no idea how much nicer it is to write and express a lot of this logic in modern javascript, rather than nginx configs and VCLs.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#63

Post by Matthias247 » Tue, Jul 03, 2018, 6:48 PM UTC

kentonv wrote: post #59

Matthias247 wrote: post #43

Earlier quoted context omitted.

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…

Thanks for the explanation!

Yes, I guess a part of my question was whether the destructors/finalizers that the JS object bindings in C++ might impose are called fast enough to guarantee isolation and prevent resource leakage. Looks like in your case that happens through the request scoping.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#64

Post by skunkworker » Wed, Jul 04, 2018, 6:13 AM UTC

zackbloom wrote: post #51

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

Interesting, I'm glad to know that raw access to the Cache API is being added, when I contacted Cloudflare about this a number of months ago at the time they didn't support this. For my edge CDN needs I will reevaluate cloudflare workers soon.

On the first paragraph we have shifted some computationally heavy and horizontally restricted functions from our own servers to Lambda, this allows us to instantly scale to meet our non-consistent demand. With the lambda workers we are using we are averaging 5 to 11s of execution time with approximately 800mb of memory and utilize the cpu heavily. If Cloudflare workers ever expanded to allow for a similar scope I would definitely take a second look at it.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#65

Post by JohnDotAwesome » Thu, Jul 05, 2018, 2:00 PM UTC

adreamingsoul wrote: post #61

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…

I haven't dug too deep into this, but when loading view-source: https://jake.lol/clock I'm seeing on average 14 second load times. Does this happen for anyone else?

That seems right. Should probably be longer. Each second, a new chunk is emitted with the appropriate html to hide the old clock element and show the new.