How To Reduce Cold Starts for Java Serverless Applications in AWS
summary
Java cold starts drop a lot when specific tactics are applied: enabling AWS Lambda SnapStart cuts P90 from ~3.5s to ~2s and with priming to ~1.3s (≈60–70% reduction); switching to GraalVM Native Image yields the best single-call result (~0.5s) but requires Linux native builds, heavy CI RAM and reflection config; deployment/snapshot creation takes ~2–2.5 minutes and SnapStart cache expires after two weeks; use ~1GB memory and the AWS CRT HTTP client for further improvements.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:44Java popularity
- 2:17Life of the Java (Serverless) developer on AWS
- 5:10Serverless with Java challenges
- 5:55Challenge No. 1
- 13:05Best practices & recommendations
- 19:08AWS SnapStart
- 26:42AWS SnapStart challenges & limitations
- 33:40Best practices & recommendations
- 39:06AWS SnapStart deployment & invocation
- 41:33GraalVM
- 44:50GraalVM conclusions
- 48:51Word of caution
- 51:12Outro
related talks
46mReduce Cold Starts for Java Serverless Applications in AWS
53mHigh performance Serverless Java on AWS
46mThawing Java on AWS Lambda Reducing Cold Start Times from 11 Seconds to 1
51mAdapting Java for the Serverless world!
19mTen things that improve the performance of your Java based AWS Lambda
34mThawing Java on AWS Lambda
44mHow to develop, run and optimize Spring Boot 3 application on AWS Lambda
40mAWS Lambda SnapStart: Dramatically reduce cold starts for your Java functions