CODEWITHSUNDEEP
javaperformancespring-bootstartup
steady rain
steady rain

Reputation: 2336

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:

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:

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.

Upvotes: 184

Views: 173138

Answers (12)

vvauban
vvauban

Reputation: 485

Using native image speeds up more than 20 times the batch start up.

Check this article: https://foojay.io/today/speed-up-your-spring-batch-with-native-image-and-graalvm/

For Spring Batch applications, Native Images are a game-changer.

  1. Instantaneous startup: From 4 seconds to 0.2 seconds.
  2. Perfect for batch jobs: Jobs that start, process, and exit benefit the most.
  3. Lower memory usage: No JVM, no warm-up, no extra overhead.

By using GraalVM Native Image, you can build batch jobs that are fast, efficient, and perfectly suited for cloud environments where "scale to zero" is essential.

If you're dealing with micro-batch jobs that run for seconds, Native Image is a must-have. If your batch jobs are long-lived (running for hours), the benefit is less significant, but for fast, one-shot batch jobs, Native Image is unbeatable.

Upvotes: 0

Paul Whelan
Paul Whelan

Reputation: 16799

Checkout the Spring Boot Startup Report

https://github.com/maciejwalkowiak/spring-boot-startup-report

Spring Boot Startup Report library generates an interactive Spring Boot application startup report that lets you understand what contributes to the application startup time and perhaps helps to optimize it. startup report available in runtime as an interactive HTML page generating startup reports in integration tests flame chart search by class or an annotation

Features

  • startup report available in runtime as an interactive HTML page
  • generating startup reports in integration tests
  • flame chart
  • search by class or an annotation

Very cool utility IMHO.

Upvotes: 3

Abhijit Sarkar
Abhijit Sarkar

Reputation: 24637

The other answers don't go into the depth I like to see and provide 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.

Upvotes: 95

naXa stands with Ukraine
naXa stands with Ukraine

Reputation: 37993

WARNING: If you don't use Hibernate DDL for automatic DB schema generation and you don't use L2 cache, this answer is NOT applicable to you. Scroll ahead.

My finding is that Hibernate adds significant time to application startup. Disabling L2 cache and database initialization results in faster Spring Boot app startup. Leave cache ON for production and disable it for your development environment.

application.yml:

spring:
  jpa:
    generate-ddl: false
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        cache:
          use_second_level_cache: false
          use_query_cache: false

Test results:

  1. L2 cache is ON and ddl-auto: update: 54 seconds

     INFO 5024 --- [restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 23331 ms
 INFO 5024 --- [restartedMain] b.n.spring.Application : Started Application in 54.251 seconds (JVM running for 63.766)

  2. L2 cache is OFF and ddl-auto: none: 32 seconds

     INFO 10288 --- [restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 9863 ms
 INFO 10288 --- [restartedMain] b.n.spring.Application : Started Application in 32.058 seconds (JVM running for 37.625)

Gained 22 seconds! Now I wonder what will I do with all this free time

Upvotes: 2

naXa stands with Ukraine
naXa stands with Ukraine

Reputation: 37993

I find it strange nobody suggested these optimizations before. Here're some general tips on optimizing project build and startup when developing:

  • exclude development directories from antivirus scanner:
    • project directory
    • build output directory (if it's outside of project directory)
    • IDE indices directory (e.g. ~/.IntelliJIdea2018.3)
    • deployment directory (webapps in Tomcat)
  • upgrade hardware. use faster CPU and RAM, better internet connection (for downloading dependencies) and database connection, switch to SSD (today NVMe SSD is the most performant storage). a video card doesn't matter.
  • use latest Gradle and JVM versions. Source: easy performance improvements.
  • parallel execution. By using more concurrent processes, parallel builds can reduce the overall build time significantly.

WARNINGS

  1. the first option comes for the price of reduced security.
  2. the second option costs money (obviously).

Upvotes: -3

Niraj Sonawane
Niraj Sonawane

Reputation: 11115

Spring Boot 2.2.M1 has added feature to support Lazy Initialization in Spring Boot.

By default, when an application context is being refreshed, every bean in the context is created and its dependencies are injected. By contrast, when a bean definition is configured to be initialized lazily it will not be created and its dependencies will not be injected until it’s needed.

Enabling Lazy Initialization Set spring.main.lazy-initialization to true

When to Enable Lazy Initialization

lazy initialization can offer significant improvements in start up time but there are some notable downsides too and it’s important to enable it with care

For more details please check Doc

Update:

Spring Boot Spring Boot 2.4.0 - Startup Endpoint

Spring Boot 2.4.0 has added a new Startup endpoint that can be used to identify beans that are taking longer than expected to start. You can get more details about the Application Startup tracking here

Upvotes: 33

Daulet Kadirbekov
Daulet Kadirbekov

Reputation: 19

In my case, there was too much breakpoints. When I clicked "Mute Breakpoints" and restarted application in debug mode, application started in 10 times faster.

Upvotes: -5

Przemek Nowak
Przemek Nowak

Reputation: 7713

Well there is entire list of possible actions described here: https://spring.io/blog/2018/12/12/how-fast-is-spring

I will put the most important notes from Spring side (adjusted a little bit):

  • Classpath exclusions from Spring Boot web starters:
    • Hibernate Validator
    • Jackson (but Spring Boot actuators depend on it). Use Gson if you need JSON rendering (only works with MVC out of the box).
    • Logback: use slf4j-jdk14 instead
  • Use the spring-context-indexer. It’s not going to add much, but every little helps.
  • Don’t use actuators if you can afford not to.
  • Use Spring Boot 2.1 and Spring 5.1. Switch to 2.2 and 5.2 when they are available.
  • Fix the location of the Spring Boot config file(s) with spring.config.location (command line argument or System property etc.). Example for testing in IDE: spring.config.location=file://./src/main/resources/application.properties.
  • Switch off JMX if you don’t need it with spring.jmx.enabled=false (this is the default in Spring Boot 2.2)
  • Make bean definitions lazy by default. There’s a new flag spring.main.lazy-initialization=true in Spring Boot 2.2 (use LazyInitBeanFactoryPostProcessor for older Spring).
  • Unpack the fat jar and run with an explicit classpath.
  • Run the JVM with -noverify. Also consider -XX:TieredStopAtLevel=1 (that will slow down the JIT later at the expense of the saved startup time).

The mentioned LazyInitBeanFactoryPostProcessor (you can use it for Spring 1.5 if you cannot apply flag spring.main.lazy-initialization=true available from Spring 2.2):

public class LazyInitBeanFactoryPostProcessor implements BeanFactoryPostProcessor {

  @Override
  public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
      for (String beanName : beanFactory.getBeanDefinitionNames()) {
        BeanDefinition definition = beanFactory.getBeanDefinition(beanName);
        definition.setLazyInit(true);
      }
  }
}

You can also use (or write your own - it's simple) something to analyse beans initialization time: https://github.com/lwaddicor/spring-startup-analysis

Hope it helps!

Upvotes: 9

Brent Bradburn
Brent Bradburn

Reputation: 54999

If you're trying to optimize development turn-around for manual testing, I strongly recommend the use of devtools.

Applications that use spring-boot-devtools will automatically restart whenever files on the classpath change.

Just recompile -- and the server will restart itself (for Groovy you only need to update the source file). if you're using an IDE (e.g. 'vscode'), it may automatically compile your java files, so just saving a java file can initiate a server restart, indirectly -- and Java becomes just as seamless as Groovy in this regard.

The beauty of this approach is that the incremental restart short-circuits some of the from-scratch startup steps -- so your service will be back up and running much more quickly!

Unfortunately, this doesn't help with startup times for deployment or automated unit testing.

Upvotes: 1

pczeus
pczeus

Reputation: 7868

As described in this question/answer, I think the best approach is to instead of adding only those you think you need, exclude the dependencies you know you don't need.

See: Minimise Spring Boot Startup Time

In summary:

You can see what is going on under the covers and enable debug logging as simple as specifying --debug when starting the application from the command-line. You can also specify debug=true in your application.properties.

Also, you can set the logging level in application.properties as simple as:

logging.level.org.springframework.web: DEBUG logging.level.org.hibernate: ERROR

If you detect an auto-configured module you don't want, it can be disabled. The docs for this can be found here: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#using-boot-disabling-specific-auto-configuration

An example would look like:

@Configuration
@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
public class MyConfiguration {
}

Upvotes: 13

luboskrnac
luboskrnac

Reputation: 24591

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.

Upvotes: 82

user4415984
user4415984

Reputation:

To me it sounds like you're using a wrong configuration setting. Start by checking myContainer and possible conflicts. To determine who is using the most resources you have to check the memory maps (see the amount of data!) for each dependency at a time - and that takes plenty of time, as well... (and SUDO privileges). By the way: are you usually testing the code against the dependencies?

Upvotes: -10

Related Questions