Today, I finally had some time to play with @springboot 2.2 in #AWS #Lambda using Serverless Java Container (github.com/awslabs/aws-se…). Spring Boot 2.2 introduces start time improvements as well as global lazy initialization (spring.io/blog/2019/10/1…). \thread
The AWS Lambda function I tested with is configured with 512Mb of memory running the stock Java 8 runtime. I used the basic pet store sample from the Serverless Java Container library (github.com/awslabs/aws-se…)
First a test with Spring Boot 2.1.9.RELEASE to set a performance baseline. The X-Ray trace says that the overall cold start execution took 6.9 seconds. 5.7 for the initialization and 849ms for the actual request processing. 
Next, I just updated the Spring Boot dependency to 2.2.0.RELEASE, without changing any settings, and re-deployed my stack. The same request took 5.6 seconds (~19% faster). 4.6 for the initialization (-19%) and 621ms for the actual request processing (-26%).
Now you may rightly ask how a gain of 19% in init and 26% in execution time averages to 19% overall . I believe the actual JVM start time had an impact here. It was slightly slower in the second test (the white space before the initialization)
Next, I enabled lazy initialization of all components by adding an application.yml file with the required settings.
Keep in mind that the global lazy initialization property can work together with the @ Lazy annotation in your code. You could enable global lazy initialization and disable it for some components by annotating them with @ Lazy(false)
Running the same test on the new application gives me a total time of 7.2 seconds (+29% vs 2.2.0.RELEASE and +4% vs 2.1.9.RELEASE). The initialization, as expected, is faster with 4.1 seconds (-10%) and the execution is much slower with 2.8 seconds (+360%). Let's dive deeper
Looking at the logs for the Lambda function, it looks like Spring Boot deferred the initialization of the DispatcherServlet (after the start log line). This means that the CPU available to the function's sandbox was already throttled to an amount proportional to the 512Mb
Back of the napkin maths tells us that the DispatcherServlet construction initialization took ~500ms during Lambda's init time (with more CPU access). Whereas attempting to perform the same operation during the handler execution took ~2.2 seconds.
In summary, the startup performance improvements in Spring Boot 2.2 are significant (~20%) - that's a good thing. Lazy initialization, on the other hand, is a mixed bag.
We should initialize the DispatcherServlet and components that we'll need for each event during Lambda's init and defer custom components that are only used on certain routes by mixing global lazy initialization with the @ Lazy(false) annotation \fin
