17

I have an application that is getting fairly large, and the Spring start up time is about 20 seconds. For production use, this is fine, but for development, this is a big pain.

What is a good profiling tool or approach that can give me precisely the information I need to figure out what is taking so long? Maybe it's something I can optimize?

My application is a fairly typical spring/hibernate web app. There's about 50 database tables and several hundred beans (like 200-300... I didn't count). There's a few @Configurable beans. Lots of component scanning. I am also using Spring Security.

I did some primitize profiling with log4j - just at the INFO setting. Here are some of the things that are taking a bit of time:

  • INFO DefaultListableBeanFactory:555 - Pre-instantiating singletons - 2 seconds
  • INFO SessionFactoryImpl:202 - building session factory - 2 seconds
  • INFO HibernateTransactionManager:415 - Using DataSource [com.mchange.v2.c3p0.ComboPooledDataSource......] of Hibernate SessionFactory for HibernateTransactionManager - 7 seconds

There are a couple of things that take .5 to maybe 1 second at the most, but these 3 were the largest ones.

egervari
  • 22,372
  • 32
  • 121
  • 175
  • You might be interested in [SPR-8767 - Parallel bean initialization during startup](https://jira.springsource.org/browse/SPR-8767) – Tomasz Nurkiewicz Nov 24 '11 at 07:26
  • 1
    Interesting. I find it amusing that the Spring person said they wouldn't consider this until a number of people complained that it was too slow. Am I alone? I thought it was slow since 2002 :/ No matter how many computers I go through every few years, I can always count on Spring start up times being slow. – egervari Nov 24 '11 at 07:42
  • I think he meant that they would consider it when enough people will complain it affects productivity +1 btw good question :) – Liviu T. Nov 24 '11 at 07:58

4 Answers4

1

One option you can try is to use the default-lazy-init option to lazily initialize the beans. Spring initializes all singleton scoped beans during initialization. Read Lazily-instantiated beans section of the reference doc.

Make sure to parameterize the value so that you can change it to true during dev time and false during production deployment.

Component scanning is Slow. Refer to this post on how to disable this when you use Autowiring.

Community
  • 1
  • 1
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
  • Shucks, I am using @Autowired for my beans, not the xml :/ I'll try it with the beans top-level attribute. I hope it works – egervari Nov 24 '11 at 07:35
  • I can't seem to get spring to use the properties file with the top-level one. It doesn't matter though. It makes very little difference when I even hardcode it :( – egervari Nov 24 '11 at 07:39
  • I can't get the beans to not pre-instantiate either. – theblang Apr 12 '13 at 15:37
0

I'm saddened that all of the answers so far focus on how to improve performance and none of them actually help you do analysis. I've used YourKit to great effect in other profiling problems, but can't speak to it's usefulness with Spring startup.

I've had good success splitting my spring configuration into separate files and only loading the files needed for a particular test. This works especially well for me because I'm using Camel which is expensive to start and not used by most of my tests. I've been using H2 so that I can run tests of my DAOs + Services against a database without any complex startup/shutdown (though it took a while to get all that wired together successfully). However, I still have a problem starting up the whole app for interactive testing. It's slow for me too.

Spina
  • 8,986
  • 7
  • 37
  • 36
-1

20 seconds, to startup the application. that doesn't matter. What's matter is the time you need to run your test cases!

  • So write your tests with Mocks that do not need to startup spring at all.
  • For the more integration like tests, try to split the configuration, so that only the beans are initialized that are needed for some bunch of tests.
Ralph
  • 118,862
  • 56
  • 287
  • 383
  • 4
    I've been burned many times when service-layer tests did not run against a real database. There are just so many dumb hibernate issues and things that can go wrong when you mock out the dao layer. I also don't see much point testing the controllers as unit tests either - testing the annotations and the whole stack is the only kind of test that actually has any real value. If Hibernate didn't have so many gotchas and weird run-time scenarios that cannot be caught/tested for at the dao layer, I would agree, but I think it's very possible one can get burned by mocking with spring applications. – egervari Nov 24 '11 at 16:10
-1

You can use Spring insight also.

lalit
  • 1,485
  • 2
  • 17
  • 32