I’m due to give a talk on Java serverless at the end of this month. The difference between standard lambdas, Snapstart and provisioned concurrency is simple in theory – but digging into this has proved complicated. I’ve been using the simplest lambda possible, printing a single string to the command line. In this situation an unoptimised lambda proved the fastest option, although a ‘primed’ snapstart lambda (one that calls the handler method before the CRaC checkpoint) was only slightly slower.
Running my simple lambda produced the following output:
| Request | Init Duration (ms) | Duration (ms) | Billed Duration (ms) |
| 1st execution | 438.23 | 209.36 | 210 |
| 2nd execution | – | 10.54 | 11 |
| Execution after 30 minutes | 455.72 | 258.06 | 259 |
What I hadn’t expected here was for both the init duration and duration to both be slower on the first request. I was also shocked that the simplest lambda possible was taking so long to run. I’m aware that one query is not statistically relevant, but this matches what I’ve seen on other occasions.
I tried the same thing with the Snapstart lambda. My first attempts to do this didn’t work, calling the lambda in the normal way:
| Request | Init Duration (ms) | Duration (ms) | Billed Duration (ms) |
| 1st execution | 472.25 | 212.41 | 213 |
| 2nd execution | 7.12 | 8 | |
| Execution after 30 minutes | 500.80 | 223.55 | 224 |
I recreated the Snapstart lambda then tried explicitly publishing it to see if that was what was wrong. I had to execute the test against the specific version and this produced different Cloudwatch logs and speeds:
| Request | Restore Duration (ms) | Duration (ms) | Billed Duration (ms) |
| 1st execution | 660.45 | 269.75 | 473 |
| Following day | 703.86 | 256.52 | 239 |
I decided to make the timings more obvious by adding a 6s sleep in the lambdas constructor and a 3s sleep in the handler method.
| Request | Restore Duration (ms) | Duration (ms) | Billed Duration (ms) |
| 1st execution | 739.57 | 3250.47 | 3455 |
| Following Day | 755.28 | 3235.88 | 3420 |
This lambda demonstrates that the restore duration does not recreate the lambda, but we can see that there is a restore penalty for snapstart which is slightly longer than that for a non-snapstart lambda when the lambda is simple. There is still what we might refer to as a ‘cold start’, albeit a reduced one. (I am assuming here that the cold start does indeed call the constructor and need to go back and confirm this!)
While looking into this, I checked what I was seeing against the result in Max Day’s Lambda cold start analysis. The results yesterday (Saturday 11th May) included the following:
| Runtime | Cold start Duration (ms) | Duration (ms) |
| C++ (fastest available) | 12.7 | 1.62 |
| GraalVM Java 17 | 126.86 | 77.60 |
| NodeJS 20 | 138.43 | 13.53 |
| Java 17 | 202.28 | 8.28 |
| Quarkus | 239.97 | 211.12 |
| Java 11 Snapstart | 652.48 | 42.48 |
I’d long wondered why Day was getting such poor results from Snapstart. Now, looking at the above results, this makes sense – Snapstart only becomes helpful for complicated lambdas. The thing I’m now wondering is how come Day’s Java 17 start time is so low.
One other trick I’ve seen, which has worked for me it to invoke the lambda handler in the beforeCheckpoint method, which ensures that the stored Snapstart image includes as much of the JIT compilation as possible. This seems to work with start times of around 650ms vs 1000ms for a straightforward Snapstart lambda.
The next step is to repeat these investigations for a lambda with a severe cold start problem – which I think should happen with S3/DynamoDB access.