Tim Kye
Tim Kye
Aug 22, 2017 · 1 min read

There is some excellent advice in this article around testing and monitoring, but equally bad advice on actually writing the lambda.

  1. 1800ms to start a Node lambda is pretty bad. Startup time is a function of the amount of code you parse and load into memory, and libraries like lodash cost you a lot here. You should be targeting <1mb, preferably less than 100kb, for a node lambda. This will give you <500ms cold starts.
  2. Lambda warmers are costly, and if you optimize your cold start times, unnecessary. They also only keep your lambdas warm for a single request, multiple concurrent requests will still get cold lambdas. This simply doesn’t scale.
  3. Module bundlers are unecessary and sometimes actually *harmful* to lambdas. The raw KB size of the lambdas does not impact cold start or warm start, just the amount of code. Every bundler adds a small layer of indirection that increases the amount of code and run time of the lambda. Just zip your code up and deploy it, you will get better performance, and you wont ruin your line numbers in errors.
  4. 3rd party packages are great, but because of the extreme sensitivity of loaded code in a lambda you need to exercise caution when pulling them in. the request library, for example, is 1mb, and takes about 800ms to cold start. There are much smaller libraries, or easy to write wrappers around the built in http(s) modules that can cold start in <10ms. Be *very* careful before pulling in 3rd party packages; make sure they are small and purpose-built.

)

    Tim Kye

    Written by

    Tim Kye