Cache by-type lookups in DefaultListableBeanFactory [SPR-6870]

[spring-projects-issues]

Eberhard Wolff opened SPR-6870 and commented

The Autowiring algorithms tries to work out the dependencies by building up the Beans. If this fails, a BeanCreationException is thrown, caught and then a different way to handle the dependencies is tried. In some situations this results in slow performance and it is probably also not the nicest programming style.

---

Affects: 2.5.6

Attachments:

• perf305MainPatch.html (110.13 kB)
• perf305stock.html (120.62 kB)
• perfDiffStockVsPatch1.html (154.63 kB)
• SPR6870.patch (2.63 kB)

Sub-tasks:

• Backport "Cache by-type lookups in DefaultListableBeanFactory" [SPR-9448] #14083 Backport "Cache by-type lookups in DefaultListableBeanFactory"

Issue Links:

• Major Performance Problem in ApplicationContext Creation and Prototype Bean Lookup by Type [SPR-9296] #13934 Major Performance Problem in ApplicationContext Creation and Prototype Bean Lookup by Type ("is duplicated by")
• Improve performance of DefaultSingletonBeanRegistry.getSingletonNames(..) for high-concurrent-load applications [SPR-7949] #12604 Improve performance of DefaultSingletonBeanRegistry.getSingletonNames(..) for high-concurrent-load applications ("is duplicated by")
• Improve performance of bean lookup by type for DefaultListableBeanFactory [SPR-8095] #12750 Improve performance of bean lookup by type for DefaultListableBeanFactory ("is duplicated by")

Referenced from: commits 841d953, 0d18deb, db1cb13, f75c01d, 4c7a1c0

45 votes, 45 watchers

[spring-projects-issues]

Kristian Rosenvold commented

This problem is really bad if you use a lot of web-scoped beans and @Autowired with web-scoped beans currently uses about 75% of our total CPU time on our web server. Since the factory is not caching anything by type, it ends up iterating the entire factory a lot. And web-scoped beans are created per-request.

[spring-projects-issues]

Kristian Rosenvold commented

And yes, this applies to spring 3.0 too. The caching really needs to be updated to understand "by type".

[spring-projects-issues]

Kristian Rosenvold commented

It also severely affects start-up time of your application context. About 50-75% of our application context startup-time is spent iterating the application context to determine autowire-by type.

[spring-projects-issues]

j w commented

+1 autowiring by type is inefficient and in my profiling is taking a large percentage of the request/response time.

[spring-projects-issues]

Kristian Rosenvold commented

There is now a workaround !

http://jawspeak.com/2010/11/28/spring-slow-autowiring-by-type-getbeannamesfortype-fix-10x-speed-boost-3600ms-to/

[spring-projects-issues]

j w commented

Thanks Kristian,

My solution was not ideal, but I hope it helps you. I'm happy to contribute a patch if Spring wants it.

[spring-projects-issues]

Lari Hotari commented

Please fix this issue. Add caching to the DefaultListableBeanFactory.getBeanNamesForType method. This is a performance hotspot for many Spring applications (like Grails).

There should be caching for autowireBeanProperties and autowireByName too. Grails has caching for autowireByName in the DefaultListableBeanFactory implementation it uses: https://github.com/grails/grails-core/blob/master/grails-core/src/main/groovy/org/codehaus/groovy/grails/commons/spring/ReloadAwareAutowireCapableBeanFactory.java . Caching should be provided by default.

[spring-projects-issues]

Lari Hotari commented

Might be related to #12604.

[spring-projects-issues]

Lari Hotari commented

This issue might also be related to #12643 .

[spring-projects-issues]

Kristian Rosenvold commented

The enclosed patch adds caching to DefaultListableBeanFactory#getBeanNamesForType, providing a huge boost to any users of @Autowired on non-singleton beans. Even container startup-time is significantly improved, we saved 20% on overall startup time of our 1100 bean ApplicationContext.

In a running server environment (for a typical web application using web scopes and @Autowired) this patch will provide a similar reduction in overall cpu usage.

The patch is applied over 3.0.5 but applies cleanly at r4225 on trunk.

The patch is entirely non-functional and adds no new tests but it breaks no tests either. There are several tests that verify that the caching does not break anything, something I repeatedly discovered while making the patch.

I have also enclosed a profiler report showing the loading of the application context before and after this patch, and also a diff-only report. The reports are not complete, but shows running one wired integration test with 860 autowired dependencies from a pool of 1021 beans (there is no external io in this test)

[spring-projects-issues]

mck commented

There's (possibly related) performance patch for web applications using non-singleton beans submitted in #12604
This patch really is just the beginnings of improving the bean factory code to use ReadWriteLocks instead of hard synchronization statements...

[spring-projects-issues]

Kristian Rosenvold commented

This patch operates at a higher level in the stack than the #12604 patch and applying this patch will render the #12604 patch useless. I have not tried the patch at #12604, but I did another patch a couple of years ago using readerwriterlocks that turned out to be very prone to deadlocks in highly concurrent environments. At the time I think I decided this was a fundamental problem of using readerwriterlocks in this setting. This patch has no deadlock potential.

[spring-projects-issues]

Aaron Digulla commented

Any chance to see some work on this? The performance of looking up Spring beans by type is a bother for us as well.

We solved this outside of Spring by using this workaround:

getBean(Class<T> type) {
    String name = type.getName() + "#0";
    return getBean( name, type );
}

The idea is that for most singletons, there is only a single implementation, so the ID can be omitted and Spring will use the type of the bean to generate a name. This means that you need to do some extra work for interfaces or that you must always request beans using interface by a specific ID and never by type.

But it's a poor solution. It's pretty simple to cache the bean definition lookup in getBean(Class<T> type) and that would give a huge performance boost without the need for any hacks.

[spring-projects-issues]

Mindaugas Žakšauskas commented

Spring, please solve this. Here's my story:

http://stackoverflow.com/questions/9429612/spring-wiring-by-type-is-slower-by-magnitude-than-wiring-by-name

[spring-projects-issues]

Mike Youngstrom commented

I've been told this is a risky fix because it is right in the core of some complex code. NOW is the perfect time attempt to fix this since you are so early in the 3.2 release cycle!