Parallel bean initialization during startup [SPR-8767]

[spring-projects-issues]

Tomasz Nurkiewicz opened SPR-8767 and commented

Spring should provide a way (possibly a BeanFactory with a different ConfigurableListableBeanFactory#preInstantiateSingletons implementation) to initialize singleton non-lazy beans on startup in parallel using a thread pool. This could significantly reduce startup (and maybe shutdown) time by creating and initializing independent beans concurrently.

The algorithm is pretty simple in principle. Whereas the normal bean factory creates beans in single thread in rather random order, this implementation should:

1. Find all bean definitions that don't have any unresolved dependencies.
2. Schedule creation of each bean found in 1. in a separate concurrent task to allow parallel creation
3. When any of the tasks scheduled in 2. is completed go to 1.

The algorithm stops when all beans are created.

Implementation notes:

• circular dependencies might require extra care
• bean factory should create a thread pool with configurable number of threads and shut it down after all beans are created

---

Affects: 3.1 RC1

Reference URL: http://forum.springsource.org/showthread.php?105896-Initialize-spring-beans-in-parallel-at-startup

Issue Links:

• Parallelize Component Scanning to Improve Spring Startup Time [SPR-9887] #14520 Parallelize Component Scanning to Improve Spring Startup Time ("is duplicated by")
• Threads bottlenecking in DefaultSingletonBeanRegistry when using Wicket's @SpringBean annotation for injection [SPR-5360] #10033 Threads bottlenecking in DefaultSingletonBeanRegistry when using Wicket's @SpringBean annotation for injection
• Parallelize Component Scanning to Improve Spring Startup Time [SPR-9887] #14520 Parallelize Component Scanning to Improve Spring Startup Time
• Initialization blocked by multi-threaded event publishing [SPR-16357] #20904 Initialization blocked by multi-threaded event publishing
• Asynchronous initialization of beans during startup [SPR-14920] #19487 Asynchronous initialization of beans during startup
• Background initialization option for JPA EntityManagerFactory / Hibernate SessionFactory [SPR-13732] #18305 Background initialization option for JPA EntityManagerFactory / Hibernate SessionFactory
• Add a functional way to register a bean [SPR-14832] #19398 Add a functional way to register a bean

80 votes, 77 watchers

[spring-projects-issues]

Chris Beams commented

Hi Tomasz,

Reading through the linked forum thread, Marten's suggestion hits the nail on the head

The problem here, imho, is that you are mixing bean construction and bean initialization.

The latter is something you (judging from your post) want to do in parallel. The easiest approach, I guess, is to create an ApplicationListener which listens to ContextRefreshedEvents. (This is fired when the context is up) and which starts initializing the caches, you could plugin a TaskExecutor for this which utilizes the servers threadpool, which in turn should utilize the underlying hardware to its fullest...

Best of both worlds imho...

(http://forum.springsource.org/showthread.php?105896-Initialize-spring-beans-in-parallel-at-startup&p=352702#post352702)

While it is conceptually straightforward to imagine the container introducing concurrent bean initialization, in practice it would be anything but. We would need to see quite a bit of feedback and demand that Spring container initialization is fundamentally too slow to seriously consider this kind of change. Again, given the specific scenario in the forum post, it appears that the user can make changes that would both solve the startup time problem and probably improve the design of his program in the process.

Feel free to comment further if you think there is a compelling case that's been missed here, and we can leave this open for further comments and votes to that effect. Otherwise I'll close as won't fix for now.

[spring-projects-issues]

Niklas Schlimm commented

Hi Chris,
we're currently working on a migration of over 50 web applications to SpringIOC. Startup time is a big issue 'cause we need quick startup during development and (more important) in production environment. Since Spring does not support concurrent singleton bean instantiation we have a startup time of out complete production environment of ~2h 30 Minutes. which is not acceptable to our operations teams. We just ,igrated from a proprietary container solution that we developed. That proprietary container supported parallel instantiation. Now, we have to argue why we migrated to Spring ... to us, this is not a minor issue and we would highly appreciate any progress on this.

With regards to the solution it should be something like a "managed task executor" 'cause ideally the concurrent threads have the container managed thread context (JNDI, JPA resources must be accessible etc.). Therefore the solution is not so straight formward imho.

Best regards,
Niklas

[spring-projects-issues]

Chris Beams commented

Niklas,

2h 30m is a very long time indeed, but again, I would encourage a more pragmatic approach.

For the majority of Spring applications, container startup time is not an issue. We can be fairly certain of this simply because it is not a complaint we often encounter here in JIRA, in our forums, at conferences or with paying customers. When it does come up as a concern, we usually advise profiling the application to determine exactly which beans are causing the slowdown, and taking specific action to reduce the impact. Marten's suggestion that I quoted above would be perfectly adequate in many cases.

The upside of parallelizing bean initialization in the Spring container could be significant for a minority of applications using Spring, while the downsides - the inevitable bugs, added complexity and unintended side effects - would affect potentially every application using Spring. Not an attractive outlook, I'm afraid.

I'm resolving this issue as Won't Fix because indeed it is very unlikely that we would introduce a change of this magnitude into the core framework at this point without a very strong rationale.

Users are free to reopen this issue and add new comments, and continue to add votes if there are arguments that have not yet been heard.

[spring-projects-issues]

Niklas Schlimm commented

Hi Chris,

understand your view point. Thanks for the comprehensive reply.

Cheers,
Niklas

[spring-projects-issues]

Adib Saikali commented

I think parallel startup of Spring is very important, in my application spring is taking up 50% of my startup time, reducing that would be very helpful during development a major time saver.

[spring-projects-issues]

Ragnar Rova commented

Please see https://github.com/gredler/spriths for an experimental example implementation. Seems like the spriths implementation goes far into making it work. The author of spriths mentions #10033 that needs to be solved in order to make parallel startup thread-safe.

It would be nice if the framework at least did not stand in the way of users wanting parallel startup.

[spring-projects-issues]

Jonatan Jönsson commented

I think a ConfigurableListableBeanFactory#setConcurrentInstantiationOfSingletons(boolean) would be great. Default to non-concurrent but make it super easy to get a parallel version.

[spring-projects-issues]

Scott Murphy commented

For a single instance web application, the speed of Spring initialization is fine. However, when you have an application that uses 20+ instances, the slowness of Spring initialization begins to a have a detrimental impact on the ability to scale dynamically. We are currently feeling major pain using Spring on App Engine. If Spring supported a multi-threaded start up, we would see a significant improvement in our ability to scale as well benefit from enormous cost savings.

[spring-projects-issues]

Scott Murphy commented

Is this worth revisiting now that it is 2 years later?

[spring-projects-issues]

Scott Murphy commented

"Users are free to reopen this issue"

Maybe keep this issue open so it can be voted upon?

[spring-projects-issues]

Adib Saikali commented

I think this problem has two distinct parts parallel discovery of beans and parallel initialization of beans. Both of which can be implemented separately to improve performance unless component scanning for a large application can not be made any faster.

[spring-projects-issues]

Julien Dubois commented

Start-up performance is a very important issue to me, and I think a lot of beans could be initialized in parallel. So yes this issue should stay open, it should even have a higher criticity level as far as I'm concerned.

[spring-projects-issues]

Attila Király commented

Our applications have really big spring contexts with a lof ot spring beans. Our cache initializations are already running in parallel but the applications still take a long time to start up because simply some of our beans require time (for example because loading reference data from various sources, which we need for other bean creation already) in creation/initialization before we can say they are "done".

So we would definitely benefit from a build in bean init parallelization.

[spring-projects-issues]

Deryl Spielman commented

We are struggling with this as well. Lazy loading beans helped a bit but I believe @Controller beans end up lazy loading its autowired fields anyway which doesn't improve the speed that much. Also entity manager and other data source beans in the config must be carefully set to eagerly be loaded, which is cumbersome. With all of this talk of microservices and Spring Boot it is obvious that separating out the modules in to separate projects may improve the speed, but this increases the overhead of managing independently deployed and managed services + it is a project in its own to figure out how to refactor the Spring bean autowiring dependencies.

I also attempted to define all beans in XML dynamically at startup using a custom implemented component scanning method found in some of these links. I found that it did improve the speed but not dramatically. The maintenance of ensuring the bean was dynamically created correctly was also cumbersome and did not work completely based on the complexities in having @Scope and @Qualifier.

Summary is we need monolith applications to increase their speed time and this ticket should be evaluated! Thanks.

[spring-projects-issues]

caiwei commented

I'm thinking to enhance below project: https://github.com/gredler/spriths
The basic idea of this project is Analyze bean dependencies -> Form DAG -> Parallel Bean Initialize.

To analyze the dependencies, I should handle dependencies that are set via Setter, Constructor and annotations including:
@Resource TYPE, FIELD, METHOD
@Inject METHOD, CONSTRUCTOR, FIELD
@AutoWired METHOD, CONSTRUCTOR, FIELD
For dependencies introduced by ApplicationContextAware, Lookup method injection, Class.forName, Reflect..., may unable to handle...

User is allowed to specify the parallel bean init in a context.xml as below:
<context:parallel-bean-init enabled="true" alwaysGenerate="true" dag="dag.xml"/>

a DAG is quite straightforward.
<dag>
<bean name="A">
<dependOn bean="C"/>
</bean>
<bean name="B">
<dependOn bean="C"/>
<dependOn bean="D"/>
</bean>
<bean name="C">
<dependOn bean="E"/>
</bean>
<bean name="D">
<dependOn bean="E"/>
</bean>
<bean name="E">
<dependOn bean="G"/>
</bean>
<bean name="F">
<dependOn bean="G"/>
</bean>
<bean name="G"/>
</dag>

User can always let Spring generate a dag file or specify a dag file as they wish(set alwaysGenerate="false").
We know It is almost impossible for users to create the DAG from scratch. They have to know the bean dependencies and find out all beans defined via annotation.
The typical use case is user will first generate the DAG, then they may adjust the sequences in DAG if there are any server startup failures caused by the concurrent bean initialization.

Just my 2 cents. Please share your expertise and let me know your concerns.