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 this:

https://jira.spring.io/browse/SPR-8767

would speed up things, but it's not even triaged at this point. I see some other efforts in Spring Boot itself, e.g.:

https://github.com/spring-projects/spring-boot/issues/1610

but this looks Tomcat-specific.

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.

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

Post your code. Normally only the package the application runner is defined is is scanned. If you have other packages defined for @ComponentScan those are scanned as well. Another thing is to make sure you haven't enabled debug or trace logging as generally logging is slow, very slow.

– M. Deinum
Dec 2 '14 at 7:46

If you use Hibernate it also tends to eat significant time at application start.

– Knut Forkalsrud
Mar 20 '15 at 3:08

Spring's auto binding by type coupled with factory beans has the potential to be slow one you add a lot of beans and dependencies.

– Knut Forkalsrud
Mar 20 '15 at 3:10

Or you can use caching, spring.io/guides/gs/caching

– Cassian
Mar 20 '15 at 9:47

1

Thanks all for the comments - I would not be able to post the code unfortunately (a lot of internal jars), however I'm still looking for a way to debug this. Yes, I might be using A or B or doing X or Y, which slows it down. How do I determine this? If I add a dependency X, which has 15 transitive dependencies, how do I know which of those 16 slowed it down? If I can find out, is there anything I can do later to stop Spring from examining them? Pointers like that would be useful!

– steady rain
Mar 20 '15 at 12:14

|
show 2 more comments

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 this:

https://jira.spring.io/browse/SPR-8767

would speed up things, but it's not even triaged at this point. I see some other efforts in Spring Boot itself, e.g.:

https://github.com/spring-projects/spring-boot/issues/1610

but this looks Tomcat-specific.

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.

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

Post your code. Normally only the package the application runner is defined is is scanned. If you have other packages defined for @ComponentScan those are scanned as well. Another thing is to make sure you haven't enabled debug or trace logging as generally logging is slow, very slow.

– M. Deinum
Dec 2 '14 at 7:46

If you use Hibernate it also tends to eat significant time at application start.

– Knut Forkalsrud
Mar 20 '15 at 3:08

Spring's auto binding by type coupled with factory beans has the potential to be slow one you add a lot of beans and dependencies.

– Knut Forkalsrud
Mar 20 '15 at 3:10

Or you can use caching, spring.io/guides/gs/caching

– Cassian
Mar 20 '15 at 9:47

1

Thanks all for the comments - I would not be able to post the code unfortunately (a lot of internal jars), however I'm still looking for a way to debug this. Yes, I might be using A or B or doing X or Y, which slows it down. How do I determine this? If I add a dependency X, which has 15 transitive dependencies, how do I know which of those 16 slowed it down? If I can find out, is there anything I can do later to stop Spring from examining them? Pointers like that would be useful!

– steady rain
Mar 20 '15 at 12:14

|
show 2 more comments

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 this:

https://jira.spring.io/browse/SPR-8767

would speed up things, but it's not even triaged at this point. I see some other efforts in Spring Boot itself, e.g.:

https://github.com/spring-projects/spring-boot/issues/1610

but this looks Tomcat-specific.

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.

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

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 this:

https://jira.spring.io/browse/SPR-8767

would speed up things, but it's not even triaged at this point. I see some other efforts in Spring Boot itself, e.g.:

https://github.com/spring-projects/spring-boot/issues/1610

but this looks Tomcat-specific.

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.

java spring performance spring-boot startup

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

edited Jan 1 at 21:51

naXa

14.3k892142

edited Jan 1 at 21:51

naXa

14.3k892142

edited Jan 1 at 21:51

naXa

14.3k892142

asked Dec 1 '14 at 14:37

steady rain

6311815

asked Dec 1 '14 at 14:37

steady rain

6311815

asked Dec 1 '14 at 14:37

steady rain

6311815

Post your code. Normally only the package the application runner is defined is is scanned. If you have other packages defined for @ComponentScan those are scanned as well. Another thing is to make sure you haven't enabled debug or trace logging as generally logging is slow, very slow.

– M. Deinum
Dec 2 '14 at 7:46

If you use Hibernate it also tends to eat significant time at application start.

– Knut Forkalsrud
Mar 20 '15 at 3:08

Spring's auto binding by type coupled with factory beans has the potential to be slow one you add a lot of beans and dependencies.

– Knut Forkalsrud
Mar 20 '15 at 3:10

Or you can use caching, spring.io/guides/gs/caching

– Cassian
Mar 20 '15 at 9:47

1

Thanks all for the comments - I would not be able to post the code unfortunately (a lot of internal jars), however I'm still looking for a way to debug this. Yes, I might be using A or B or doing X or Y, which slows it down. How do I determine this? If I add a dependency X, which has 15 transitive dependencies, how do I know which of those 16 slowed it down? If I can find out, is there anything I can do later to stop Spring from examining them? Pointers like that would be useful!

– steady rain
Mar 20 '15 at 12:14

|
show 2 more comments

Post your code. Normally only the package the application runner is defined is is scanned. If you have other packages defined for @ComponentScan those are scanned as well. Another thing is to make sure you haven't enabled debug or trace logging as generally logging is slow, very slow.

– M. Deinum
Dec 2 '14 at 7:46

If you use Hibernate it also tends to eat significant time at application start.

– Knut Forkalsrud
Mar 20 '15 at 3:08

Spring's auto binding by type coupled with factory beans has the potential to be slow one you add a lot of beans and dependencies.

– Knut Forkalsrud
Mar 20 '15 at 3:10

Or you can use caching, spring.io/guides/gs/caching

– Cassian
Mar 20 '15 at 9:47

1

Thanks all for the comments - I would not be able to post the code unfortunately (a lot of internal jars), however I'm still looking for a way to debug this. Yes, I might be using A or B or doing X or Y, which slows it down. How do I determine this? If I add a dependency X, which has 15 transitive dependencies, how do I know which of those 16 slowed it down? If I can find out, is there anything I can do later to stop Spring from examining them? Pointers like that would be useful!

– steady rain
Mar 20 '15 at 12:14

Post your code. Normally only the package the application runner is defined is is scanned. If you have other packages defined for @ComponentScan those are scanned as well. Another thing is to make sure you haven't enabled debug or trace logging as generally logging is slow, very slow.

– M. Deinum
Dec 2 '14 at 7:46

If you use Hibernate it also tends to eat significant time at application start.

– Knut Forkalsrud
Mar 20 '15 at 3:08

Spring's auto binding by type coupled with factory beans has the potential to be slow one you add a lot of beans and dependencies.

– Knut Forkalsrud
Mar 20 '15 at 3:10

Or you can use caching, spring.io/guides/gs/caching

– Cassian
Mar 20 '15 at 9:47

Thanks all for the comments - I would not be able to post the code unfortunately (a lot of internal jars), however I'm still looking for a way to debug this. Yes, I might be using A or B or doing X or Y, which slows it down. How do I determine this? If I add a dependency X, which has 15 transitive dependencies, how do I know which of those 16 slowed it down? If I can find out, is there anything I can do later to stop Spring from examining them? Pointers like that would be useful!

– steady rain
Mar 20 '15 at 12:14

|
show 2 more comments

7 Answers
7

active

oldest

votes

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.

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

1

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

add a comment |

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:

CPU matters. A lot.

Starting the JVM with -Xverify:none helps significantly.

Excluding unnecessary autoconfigurations helps.

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.

There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

1

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

|
show 3 more comments

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 {

}

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

add a comment |

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.

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

add a comment |

-1

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. video card doesn't matter.

answered Jan 1 at 22:05

naXa

14.3k892142

add a comment |

-2

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:

L2 cache is ON and ddl-auto: update

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)

L2 cache is OFF and ddl-auto: none

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)

Now I wonder what will I do with all this free time

answered Jan 1 at 22:27

naXa

14.3k892142

add a comment |

-6

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?

answered Mar 30 '15 at 13:15

user4415984

add a comment |

protected by cassiomolin Oct 26 '18 at 10:29

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

7 Answers
7

active

oldest

votes

7 Answers
7

active

oldest

votes

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.

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

1

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

add a comment |

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.

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

1

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

add a comment |

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.

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

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.

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

edited Oct 31 '16 at 5:19

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

answered Mar 14 '16 at 17:24

luboskrnac

15.8k54672

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

1

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

add a comment |

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

1

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

how does one run org.springframework in DEBUG mode?

– Orion Edwards
Oct 31 '16 at 4:57

did you measure this ??? Was it much faster?? In my opinion this is an exceptional case, much more important to make sure that Spring test context cache works

– idmitriev
Jul 9 '17 at 20:49

@idmitriev I just measured this on my application and my application started up at 53 seconds, compared to without exluding the autoconfiguration classes was 73 seconds. I did exclude many more classes than listed above though.

– apkisbossin
Mar 6 at 17:00

add a comment |

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

My findings are as follows:

CPU matters. A lot.

Starting the JVM with -Xverify:none helps significantly.

Excluding unnecessary autoconfigurations helps.

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.

There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

1

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

|
show 3 more comments

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

My findings are as follows:

CPU matters. A lot.

Starting the JVM with -Xverify:none helps significantly.

Excluding unnecessary autoconfigurations helps.

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.

There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

1

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

|
show 3 more comments

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

My findings are as follows:

CPU matters. A lot.

Starting the JVM with -Xverify:none helps significantly.

Excluding unnecessary autoconfigurations helps.

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.

There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

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

My findings are as follows:

CPU matters. A lot.

Starting the JVM with -Xverify:none helps significantly.

Excluding unnecessary autoconfigurations helps.

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.

There have been reports of hostname resolution being slow, but I didn't find it to be a problem for the apps I tested.

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

edited Sep 13 '18 at 13:15

kvantour

9,44431731

edited Sep 13 '18 at 13:15

kvantour

9,44431731

edited Sep 13 '18 at 13:15

kvantour

9,44431731

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

answered Apr 5 '18 at 2:07

Abhijit Sarkar

7,65874294

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

1

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

|
show 3 more comments

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

1

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

It does not seem that your project builds under gradle 4.8.1. Could you share which gradle version you used in your benchmarks?

– user991710
Jul 18 '18 at 18:19

@user991710 Based on my Gradle wrapper, I'm using v4.6. "Does not build" is a very vague statement, if you've something more specific, create a gist and post the link here. Your gist should list the steps you followed, and the error you're getting.

– Abhijit Sarkar
Jul 18 '18 at 23:44

My apologies, I was a bit unclear. Checking out the project with a clean working directory and simply performing ./gradlew clean shadowJar as in the Readme results in the following error: > The value of a manifest attribute must not be null (Key=Start-Class).. I have made no local changes.

– user991710
Jul 19 '18 at 8:17

@user991710 Not sure how it broke, but it's fixed now. Thanks for the report.

– Abhijit Sarkar
Jul 19 '18 at 9:50

Thanks for the quick response!

– user991710
Jul 19 '18 at 11:14

|
show 3 more comments

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:

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

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

An example would look like:

@Configuration

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

public class MyConfiguration {

}

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

add a comment |

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:

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

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

An example would look like:

@Configuration

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

public class MyConfiguration {

}

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

add a comment |

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:

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

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

An example would look like:

@Configuration

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

public class MyConfiguration {

}

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

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:

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

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

An example would look like:

@Configuration

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

public class MyConfiguration {

}

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

edited May 23 '17 at 12:34

Community♦

edited May 23 '17 at 12:34

Community♦

edited May 23 '17 at 12:34

Community♦

answered Sep 22 '16 at 14:44

pczeus

5,74442542

answered Sep 22 '16 at 14:44

pczeus

5,74442542

answered Sep 22 '16 at 14:44

pczeus

5,74442542

add a comment |

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.

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.

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

add a comment |

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.

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.

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

add a comment |

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.

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.

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

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.

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.

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

answered Dec 12 '18 at 21:44

nobar

26.8k1085100

add a comment |

-1

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. video card doesn't matter.

answered Jan 1 at 22:05

naXa

14.3k892142

add a comment |

-1

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. video card doesn't matter.

answered Jan 1 at 22:05

naXa

14.3k892142

add a comment |

-1

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. video card doesn't matter.

answered Jan 1 at 22:05

naXa

14.3k892142

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. video card doesn't matter.

answered Jan 1 at 22:05

naXa

14.3k892142

answered Jan 1 at 22:05

naXa

14.3k892142

answered Jan 1 at 22:05

naXa

14.3k892142

answered Jan 1 at 22:05

naXa

14.3k892142

add a comment |

-2

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:

L2 cache is ON and ddl-auto: update

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)

L2 cache is OFF and ddl-auto: none

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)

Now I wonder what will I do with all this free time

answered Jan 1 at 22:27

naXa

14.3k892142

add a comment |

-2

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:

L2 cache is ON and ddl-auto: update

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)

L2 cache is OFF and ddl-auto: none

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)

Now I wonder what will I do with all this free time

answered Jan 1 at 22:27

naXa

14.3k892142

add a comment |

-2

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:

L2 cache is ON and ddl-auto: update

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)

L2 cache is OFF and ddl-auto: none

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)

Now I wonder what will I do with all this free time

answered Jan 1 at 22:27

naXa

14.3k892142

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:

L2 cache is ON and ddl-auto: update

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)

L2 cache is OFF and ddl-auto: none

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)

Now I wonder what will I do with all this free time

answered Jan 1 at 22:27

naXa

14.3k892142

answered Jan 1 at 22:27

naXa

14.3k892142

answered Jan 1 at 22:27

naXa

14.3k892142

answered Jan 1 at 22:27

naXa

14.3k892142

add a comment |

-6

answered Mar 30 '15 at 13:15

user4415984

add a comment |

-6

answered Mar 30 '15 at 13:15

user4415984

add a comment |

-6

answered Mar 30 '15 at 13:15

user4415984

answered Mar 30 '15 at 13:15

user4415984

answered Mar 30 '15 at 13:15

user4415984

answered Mar 30 '15 at 13:15

user4415984

answered Mar 30 '15 at 13:15

user4415984

add a comment |

protected by cassiomolin Oct 26 '18 at 10:29

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu