12 ms·

The VPC startup times are insane, so we quickly move our lambdas out of that, accepting the trade off. Our normal cold starts are in the 1-2 second range, and

by Tehnix 8y ago

The VPC startup times are insane, so we quickly move our lambdas out of that, accepting the trade off. Our normal cold starts are in the 1-2 second range, and the app initialization comes after. Too high for an API facing users :/

sudhirj 8y ago
That's odd. Are you running the interpreter runtimes (NodeJS/PHP), compiled binaries (Go) or VMs like Java?
- Tehnix 8y ago
  We are using Node.js. From what I’ve seen online, Python should be the fastest though. Edit: wanted to add, that from what I’ve gathered from people testing online, bundle size didn’t really matter, but perhaps someone else has some information that points to the contrary?
  - sudhirj 8y ago
    Bundle size is rarely equivalent to size of initial executable code. i.e. I can have a giant photo of my dog in the bundle but it won't necessarily affect the start up time of the node index.js. I think there is some kind of effect in that the bundle must be downloaded to the Lambda container server from S3, but that seems pretty fast, and it's likely cached there for a while.
cddotdotslash 8y ago
We got around this with a bit of a hack - use a CloudWatch event to trigger a dummy invocation of your function every five minutes. This keeps the container "hot" and reduces the start time (and is negligible cost-wise). This won't fix the cold starts when the function scales up, but it does reduce latency for 99% of our API requests.
- vdfs 8y ago
  Isn't using a server better in this case? Or Lambda have some benefits in this setup?
  - cddotdotslash 8y ago
    It's still insanely cheap. You could have millions of executions per month and only pay $0.50. But if you needed to, it could scale up to billions of invocation nearly instantly, something a standard server would have trouble doing as easily as Lambda does.
    - markonen 8y ago
      Then again, you are doing the hacks you describe because it is not scaling up nearly instantly. The cold start delays are not only an issue when scaling from zero to one, they hit you whenever you scale the capacity up.
      - aspyker 8y ago
        This. I continue to hear about hacks of people running ping to keep a single instance warm. But that doesn't cover periodic changes in capacity needs nor spikes. I would think to avoid cold starts all together you'd need a pinger that sent exactly the load difference between peak load and current load. I would love to hear if anyone is keeping Lambdas warm at more than n=1 capacity.
        Tehnix 8y ago
        >if anyone is keeping Lambdas warm at more than n=1 capacity There are various ways to do it, but I feel that it's a very suboptimal solution, and it still won't guarentee no cold starts happen. I've personally come to the conclusion, that lambda is very nice for anything non-latency sensitive. We are still using it to great effect for e.g. processing incoming IoT data samples, which can vary quite a lot, but only happens in the backend, and nobody will care if it's 1-2 seconds delayed.

by Tehnix 8y ago

sudhirj 8y ago

That's odd. Are you running the interpreter runtimes (NodeJS/PHP), compiled binaries (Go) or VMs like Java?

Tehnix 8y ago
We are using Node.js. From what I’ve seen online, Python should be the fastest though. Edit: wanted to add, that from what I’ve gathered from people testing online, bundle size didn’t really matter, but perhaps someone else has some information that points to the contrary?
- sudhirj 8y ago
  Bundle size is rarely equivalent to size of initial executable code. i.e. I can have a giant photo of my dog in the bundle but it won't necessarily affect the start up time of the node index.js. I think there is some kind of effect in that the bundle must be downloaded to the Lambda container server from S3, but that seems pretty fast, and it's likely cached there for a while.

cddotdotslash 8y ago

We got around this with a bit of a hack - use a CloudWatch event to trigger a dummy invocation of your function every five minutes. This keeps the container "hot" and reduces the start time (and is negligible cost-wise). This won't fix the cold starts when the function scales up, but it does reduce latency for 99% of our API requests.

vdfs 8y ago
Isn't using a server better in this case? Or Lambda have some benefits in this setup?
- cddotdotslash 8y ago
  It's still insanely cheap. You could have millions of executions per month and only pay $0.50. But if you needed to, it could scale up to billions of invocation nearly instantly, something a standard server would have trouble doing as easily as Lambda does.
  - markonen 8y ago
    Then again, you are doing the hacks you describe because it is not scaling up nearly instantly. The cold start delays are not only an issue when scaling from zero to one, they hit you whenever you scale the capacity up.
    - aspyker 8y ago
      This. I continue to hear about hacks of people running ping to keep a single instance warm. But that doesn't cover periodic changes in capacity needs nor spikes. I would think to avoid cold starts all together you'd need a pinger that sent exactly the load difference between peak load and current load. I would love to hear if anyone is keeping Lambdas warm at more than n=1 capacity.
      - Tehnix 8y ago
        >if anyone is keeping Lambdas warm at more than n=1 capacity There are various ways to do it, but I feel that it's a very suboptimal solution, and it still won't guarentee no cold starts happen. I've personally come to the conclusion, that lambda is very nice for anything non-latency sensitive. We are still using it to great effect for e.g. processing incoming IoT data samples, which can vary quite a lot, but only happens in the backend, and nobody will care if it's 1-2 seconds delayed.