I'm working with a Java 8 AWS Lambda function that interfaces with an API Gateway, saves data to S3, pushes notifications via Firebase, and triggers another Lambda for background processing. I've been struggling with cold starts, originally experiencing delays of around 20 seconds, while warmed executions only took about 500ms. I set up a scheduled event to ping the Lambda every 2 minutes to keep it warm, but I still face cold starts approximately once an hour. I tried switching to provisioned concurrency with two instances, which reduced cold start times to 10 seconds, but it still doesn't reach the ideal 500ms. I'm wondering: why doesn't provisioned concurrency eliminate these delays entirely? Is it worth the cost if I can't consistently achieve low response times? Here are my Lambda stats: Java 8 on Amazon Linux 2, using x86_64 architecture, with 1024 MB memory (around 200MB used per invocation) and 512MB of ephemeral storage.
5 Answers
That 20-second start time is a bit excessive! You might want to consider changing programming languages. Java can be slow with its JVM startup. If speed is crucial, Go could be a great alternative. For easier prototyping, Python works well too.
Have you looked into adjusting your Java compilation tier? AWS has resources that suggest optimizations for Lambda performance that could significantly reduce cold starts, though be cautious as it may affect runtime optimization.
If you're relying on scheduled pings to keep your Lambda warm, it might indicate that Lambda isn't the best fit for your workload. Have you checked whether you're zipping your code or using a container? That could make a difference.
I'm going with a JAR file stored on S3 too, around 90MB. The initial S3 connection can really drag things down, right?
Have you given SnapStart a shot? It might help with the cold start issue.
I did try SnapStart before going for provisioned concurrency but didn’t notice much improvement. I guess I should give it another test.
Are you possibly exceeding the number of warm Lambdas with your concurrent requests? If you've only provisioned for 2 but your usage demands 8, that would lead to cold starts. In our experience, warming Lambdas is usually more cost-effective than moving to an always-on setup like EC2, but definitely reassess if this is a recurring issue for you.
I hear you! Java's not really the most efficient choice for Lambda—I've seen it struggle with performance.