Best practices for optimizing Lambda functions
cloudash.dev
cloudash.dev
One amazing piece of tooling I’ve come across is SST: https://serverless-stack.com/
They build on top of AWS CDK & they have a very clever way to do “local” development by injecting a websockets into your deployed lambda & you can work against real infra instead of mocks
"In addition to that, consider whether you can move initialization code outside of the handler function."
There's an example too, but this could use more emphasis. I see quite of a lot of code in the main body of lambdas that doesn't need to be run over and over, things that could be safely cached in a hashmap, etc.
To be fair, handling lambda cold start is AWS lambda 101, and initialization is the starting point. I'd say that the only people not aware of this is those who are just taking their first steps.
This requirement is even notorious in JDK lambdas, and leads to the need to use dependency injection frameworks to handle initialization and consequently favour compile-time dependency injection frameworks such as Dagger over runtime ones like Guice.
> things that could be safely cached in a hashmap, etc.
I'd add that caching data in /tmp to get it through lazy evaluation is also a quite basic technique. The contents of /tmp are preserved between some calls and checking if the data is still there is an effective technique to shave off some milliseconds.
What a weirdly bold and provably untrue claim.
AWS is, additionally, the only way of doing functions as a service.
/s
(Yah I'm mad that the title wasn't at least "AWS Lambda functions" - isn't "serverless" a funny enough name on its own for that domain?)
Not really. Given the context is clearly AWS, it's Well-Architected Framework is centered on AWS Lambdas.
If you use AWS SDK v3 and use node.js runtime 14.x, you can use top level await. Using top level await lets you more easily do async initializations outside your handler code, before invocation. This has a major benefit of reducing cold start latency when using provisioned concurrency.
See https://aws.amazon.com/blogs/compute/using-node-js-es-module...
This is one of the more annoying things about the service. Why can't AWS publish this information? I might get 4 vCPUs at 5308MB today, but there's no guarantee they won't raise that threshold to 6144MB tomorrow and cause my run times to increase. There should be a better way to figure out what my execution environment looks like than trial and error.
To be fair, once you start to be bothered with how many threads you get, I'd argue you are already way outside of AWS Lambda's domain and well inside plain old ECW/ECS territory.
Keep in mind that AWS Lambdas are appropriate for a) glue code to plug together AWS events b) offload seldomly-ran background tasks, c) rarely executed tasks, such as a terribly simple REST API that is simpler to develop and maintain as a API Gateway+Lambda app instead of, say, express/spring/flask/whatever.
Once your requirements don't unquestionably fit any of these scenarios, you have to take a very hard look at what you're doing to explain why aren't you just rolling your own web service and instead you're opting to both pay a premium and increase your maintenance needs.