Without knowing too much about your specific use case, here are two general suggestions:

1. Increase the memory allocated to your functions, which also increases CPU proportionally. Because your functions are called very infrequently, the added cost of increasing memory size will be balanced by faster cold start times and thus lower billed duration.

2. Reduce your code size: a smaller .zip, removing unnecessary require()'s in Node.js, etc. For example, if you are including the Async library just to remove a nested callback, consider forgoing that to improve performance.

Hi William.

I have the same problem.

I tried running the same code with both Java and Node. My code usings the AmazonS3Client to download a file and print it to the output stream. Here is my configuration:

Node.js
filesize:500bytes
memory limit: 128mb
timeout: 1s
Cold start: 900ms
Average time to complete all after cold start: 50ms.

Java
filesize:27mb
memory limit: 512mb
timeout: 10s
Cold start 9.5s
Average time to complete all after cold start: 50ms to 200ms. With occasional spikes if 1-2 seconds.

I have been trying to figure out the cold start delay of java for the past few days as well as the spikes. Is the cold start 10s delay under java caused by the 27mb filesize? It is very hard to compile anything smaller than this. Only the amazon sdk is about 15 mb.

Edited by: Alexandre Harvey-Tremblay on Aug 14, 2015 5:44 AM

Have you tried to use single aws service jars ?
they are available from the meaven repo.
For example use only aws-s3 jar not the whole sdk.
i had the same problem, and from 25 mb ended up with 5 mb.Just make sure you include their dependecies as well.

Edited by: panicou on Aug 16, 2015 5:19 PM

Moving one-time initialization (such as loading libraries) out of request handler in node (or into a static block in Java) may also lower your cold start overhead, especially for infrequently called / low scale functions. Forcing the code to load (e.g., by making an innocuous GET call) in this block will also ensure that the code is ready when the request hits.

The team continues to optimize cold start times, but it will always be the case that increasing the power level (via the memory setting, but really it's the CPU you're after here) is a good choice for infrequently used routines.

My cold start for a DynamoDB Stream Lambda is ~4000ms.

REPORT RequestId: 79802395-9214-4552-b086-1e328e64edbb Duration: 4155.86 ms Billed Duration: 4200 ms Memory Size: 512 MB Max Memory Used: 55 MB

And it happens every couple minutes. It seems that Lambda Java does not keep classes loaded for any length of time and keeps unload and reload them for every data batch.

And the processing time per record is abnormally slow ~200ms compared to the same code running on a micro ec2 instance ~10ms.

REPORT RequestId: 3ac86fdd-0c45-44d9-a84b-c9e980257699 Duration: 180.00 ms Billed Duration: 200 ms Memory Size: 512 MB Max Memory Used: 55 MB

Given the poor performance I had to disable it. I hope it gets improved soon.

+1

I too will be unable to use Java on Lambda until we can get some faster cold-start times.

The great pitch of Lambda is that it will automatically scale as your requests increase in number. However in its current state I wouldn't feel comfortable launching any production code for fear of not having enough requests to keep it hot.

panicou, can you expand on what you did? I'm encountering the same problem with 30MB java packages that are called infrequently and take a long time to load on a cold start.

Hi Tim. Could you explain why moving Java initialization code to a static block would improve cold start overhead? If the RequestHandler is being instantiated wouldn't initialization in the constructor be cached just the same as a static method? And if it's actually starting a new JVM that leads to long cold starts wouldn't the time be the same in any of the 3 scenarios (initialization in static / constructor / handleRequest)? Thanks!

Any solution to this yet? 1 sec+ response times are unacceptable for most web apps, even for the less used functions.

I'm running into something similar. Java executables, 6 MB in size, using max memory, but due to cold start I am still seeing response times well over 3 seconds, which is leading to a lot of user confusion (this is for a Slack chatbot, and Slack will resend requests that are not responded to in 3 seconds, so the users are getting multiple responses).

Any suggestions?