4 ms·

Interesting, we’re just about to put cloudflare workers in prod and find their approach much more flexible vs lambda@edge being possibly triggered four times at

Interesting, we’re just about to put cloudflare workers in prod and find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle. But this could significantly reduce cost if your execution time is low. How likely are you to see 1ms execution times for this stuff tho? Super simple logic should be that low I guess.. They must have a very mature execution environment to be able to offer this (if 1ms execution is achievable), cf workers have a whole set to logic to average out cpu spikes so you don’t randomly hit the 50ms limit, bc their execution of your code isn’t that deterministic I suppose.

mcpherrinm 6y ago
I don't think it's about getting 1ms execution time: It's more like having 300ms vs 301ms execution time be very similar in cost (or however the rounding worked). The firecracker microvm says startup time is under 125ms, but I have not personally done any benchmarking, though my employer does use firecracker for hosting our CI builders.
- nhoughto 6y ago
  Ah yeah makes sense. Really interesting that cf workers limit you to 50ms cpu time rather than wallclock time, makes lots of send-then-wait scenarios possible/way cheaper.
  - qwtel 6y ago
    actually there appears to be a limit to this. i’ve never been able to perform more than ~50 http requests per invocation, leading me to believe that they are “billed” with 1ms cpu time.
    - nhoughto 6y ago
      Yeah it’s not _just_ 50ms cpu, there are other constraints like 50 sub requests, 6 open connections etc. Still faaairly generous, good luck getting 50 sub requests done in 50ms if you had to measure against wallclock =)
helsinkiandrew 6y ago
> ... find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle. The lamda@edge function is executed only once but you decide when - before or after the cache and either on the request or response.
- nhoughto 6y ago
  So if I want to hook into each 4 parts of the lifecycle, I configure that and it gets executed once? Can I maintain state between inbound request->origin request->origin response->inbound response? My understanding was you can’t and it got called 4 times with different events, workers solves this by you being responsible for making the origin request (there is a simple mode where it does it for you to) with promises to manage origin response and inbound response logic.. I thought lambda@edge didn’t work like that?
  - helsinkiandrew 6y ago
    For each lambda function you specify which one of the 4 places it is called. So effectively be 4 different lambda functions, triggered independently (they could ofcourse share code). If you wanted to maintain state then I'd guess the easiest (only?) way is for the function to add headers to the HTTP request/response as it passed through.

mcpherrinm 6y ago

I don't think it's about getting 1ms execution time: It's more like having 300ms vs 301ms execution time be very similar in cost (or however the rounding worked). The firecracker microvm says startup time is under 125ms, but I have not personally done any benchmarking, though my employer does use firecracker for hosting our CI builders.

nhoughto 6y ago
Ah yeah makes sense. Really interesting that cf workers limit you to 50ms cpu time rather than wallclock time, makes lots of send-then-wait scenarios possible/way cheaper.
- qwtel 6y ago
  actually there appears to be a limit to this. i’ve never been able to perform more than ~50 http requests per invocation, leading me to believe that they are “billed” with 1ms cpu time.
  - nhoughto 6y ago
    Yeah it’s not _just_ 50ms cpu, there are other constraints like 50 sub requests, 6 open connections etc. Still faaairly generous, good luck getting 50 sub requests done in 50ms if you had to measure against wallclock =)

helsinkiandrew 6y ago

> ... find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle. The lamda@edge function is executed only once but you decide when - before or after the cache and either on the request or response.

nhoughto 6y ago
So if I want to hook into each 4 parts of the lifecycle, I configure that and it gets executed once? Can I maintain state between inbound request->origin request->origin response->inbound response? My understanding was you can’t and it got called 4 times with different events, workers solves this by you being responsible for making the origin request (there is a simple mode where it does it for you to) with promises to manage origin response and inbound response logic.. I thought lambda@edge didn’t work like that?
- helsinkiandrew 6y ago
  For each lambda function you specify which one of the 4 places it is called. So effectively be 4 different lambda functions, triggered independently (they could ofcourse share code). If you wanted to maintain state then I'd guess the easiest (only?) way is for the function to add headers to the HTTP request/response as it passed through.