I have a Lambda function written in Java which is being accessed from API Gateway. In cold start scenarios, the actual code is taking 1.5 secs to complete execution(Verified from Cloudwatch Logs) but it's taking more than 10 secs to get the final response in API Gateway. It's annoying.
I have captured the X-Ray tracers for both Cold start and Hot start scenarios.
Can anyone help me in resolving this performance issue ?
Cold Start:
Hot Start:
Possible solution to resolve cold starts written in Java: Adding more memory for lambda, and there is also one more approach to reduce the cold starts: use Graal native-image tool. The jar is translated into byte code. Basically, we would do part of the work, which is done on aws. When you build your code, on loading to AWS - select "Custom runtime", not java8.
Helpful article: https://engineering.opsgenie.com/run-native-java-using-graalvm-in-aws-lambda-with-golang-ba86e27930bf
Beware:
but it also has its limitations; it does not support dynamic class loading, and reflection support is also limited
Cold starts happen when you are not triggering any work on your lambda function for some time. So amazon just shuts down the container holding your code. The slowdown you see is just the time spent by amazon to wake up a container, loading your lambda function (can take more time if you are using static code tech such as Java, should be slower with JS for instance) and actually running it (which seems in your case negligible compared to amazon's whole job time).
Take a look at this interesting blog post about lambda cold starts: https://medium.com/thundra/dealing-with-cold-starts-in-aws-lambda-a5e3aa8f532
There are two ways forward here: a) As others have stated, increase the memory. b) Send a request to the lambda function to warm it up, and since AWS lambda containers don't have a long lifespan you'll need to do it quite frequently.
There are several factors that can contribute to an long warm up: a) If the lambda is in the vpc, attaching an ENI can take some time. b) HTTPS calls in your lambda.
Under the hood there is a container running with your lambda. The lifespan of this container isn't very long, and each time it's started up that initial request will take some time to warm up the container. The matter of fact is, you cannot avoid cold starts, they will always happen. I've personally found it's very noticeable when writing Java, that initial request always takes a lot longer.
There is a really good blog post on how to avoid cold starts here, but I'm sure you read it already.
Trick here need to worm your function either using fake call (schedler program) or using plugins like lambda warmer.
Note: Lambda design to handle event not for real world web application, if you keep worm lambda you will get same cost as EBS or EC2.
If your usecase required milisecond latancy go with compute or kubernatics.
Another thing to note is that the runtime you choose also affects cold starts.
Java runtimes has the longest cold start and Python runtimes has the shortest.
https://medium.com/@nathan.malishev/lambda-cold-starts-language-comparison-%EF%B8%8F-a4f4b5f16a62
