Speed up Spring Boot startup time

I have a Spring Boot application. I've added a lot of dependencies (unfortunately, looks I need all of them) and the startup time went up quite a lot. Just doing a SpringApplication.run(source, args) takes 10 seconds.

While that might not be much compared to what are "used" to, I'm unhappy that it takes that much, mostly because it breaks the development flow. The application itself is rather small at this point, so I assume most of the time is related to the added dependencies, not the app classes themselves.

I assume the issue is classpath scanning, but I am not sure how to:

• Confirm that is the issue (i.e. how to "debug" Spring Boot)
• If it really is the cause, how can I limit it, so it gets faster? For example, if I know that some dependency or package does not contain anything that Spring should be scanning, is there a way to limit that?

I assume that enhancing Spring to have parallel bean initialization during startup would speed up things, but that enhancement request has been open since 2011, without any progress. I see some other efforts in Spring Boot itself, such as Investigate Tomcat JarScanning speed improvements, but that is Tomcat specific and has been abandoned.

This article:

• http://www.nurkiewicz.com/2010/12/speeding-up-spring-integration-tests.html

although aimed at integration tests, suggests using lazy-init=true, however I do not know how to apply this to all beans in Spring Boot using Java configuration - any pointers here?

Any (other) suggestions would be welcome.

Solution 1:

Spring Boot does a lot of auto-configuration that may not be needed. So you may want to narrow down only auto-configuration that is needed for your app. To see full list of auto-configuration included, just run logging of org.springframework.boot.autoconfigure in DEBUG mode (logging.level.org.springframework.boot.autoconfigure=DEBUG in application.properties). Another option is to run spring boot application with --debug option: java -jar myproject-0.0.1-SNAPSHOT.jar --debug

There would be something like this in output:

=========================
AUTO-CONFIGURATION REPORT
=========================

Inspect this list and include only autoconfigurations you need:

@Configuration
@Import({
        DispatcherServletAutoConfiguration.class,
        EmbeddedServletContainerAutoConfiguration.class,
        ErrorMvcAutoConfiguration.class,
        HttpEncodingAutoConfiguration.class,
        HttpMessageConvertersAutoConfiguration.class,
        JacksonAutoConfiguration.class,
        ServerPropertiesAutoConfiguration.class,
        PropertyPlaceholderAutoConfiguration.class,
        ThymeleafAutoConfiguration.class,
        WebMvcAutoConfiguration.class,
        WebSocketAutoConfiguration.class,
})
public class SampleWebUiApplication {

Code was copied from this blog post.

Solution 2:

The most voted answer so far is not wrong, but it doesn't go into the depth I like to see and provides no scientific evidence. The Spring Boot team went through an exercise for reducing startup time for Boot 2.0, and ticket 11226 contains a lot of useful information. There is also a ticket 7939 open to adding timing information to condition evaluation, but it doesn't seem to have a specific ETA.

The most useful, and methodical approach for debugging Boot startup has been done by Dave Syer. https://github.com/dsyer/spring-boot-startup-bench

I had a similar use case as well, so I took Dave's approach of micro-benchmarking with JMH and ran with it. The result is the boot-benchmark project. I designed it such that it can be used to measure startup time for any Spring Boot application, using the executable jar produced by bootJar (previously called bootRepackage in Boot 1.5) Gradle task. Feel free to use it and provide feedback.

My findings are as follows:

1. CPU matters. A lot.
2. Starting the JVM with -Xverify:none helps significantly.
3. Excluding unnecessary autoconfigurations helps.
4. Dave recommended JVM argument -XX:TieredStopAtLevel=1, but my tests didn't show significant improvement with that. Also, -XX:TieredStopAtLevel=1 would probably slow down your first request.
5. There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.