getBean(Class) lookup performance degredation on upgrade

[Srikanth249]

When upgrading spring versions from 4.2.3 to 4.3.18 I experienced severe performance degradation in some parts of an application that happens to call ApplicationContext.getBean(Class).

Same code with 4.2.3 is returning results in 2sec, and with 4.3.18 we see around 2-3 minutes.

Any help is appreciated.

    Time difference: 4.3.18 - > Start : --- End : ----- Sun Feb 17 09:**40:09** PST 2019 --- Sun Feb 17 09:**43:22** PST 2019

    4.2.3 -> Start : --- End : ----- Sun Feb 17 09:19:02 MST 2019 --- Sun Feb 17 09:19:03 MST 2019

[sdeleuze]

Any chance you could provide a repro project?

[Srikanth249]

Hi Sdeleuze,

we do the generation of java source files dynamically (depending on the configuration), then compile and register the bean to spring context and try to fetch the bean instance from applicationContext.getBean( className).

Below is the code for registering and look up.

// bean register logic
 AbstractApplicationContext abstractApplicationContext = ( AbstractApplicationContext )applicationContext;
         DefaultListableBeanFactory beanFactory = ( DefaultListableBeanFactory )abstractApplicationContext.getBeanFactory();
         beanFactory.setAllowBeanDefinitionOverriding( true );
         AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.rootBeanDefinition( implementingClass ).getBeanDefinition();
         beanDefinition.setScope( "singleton");
         beanFactory.registerBeanDefinition( beanName, beanDefinition );


//Look up
xyz = ( T )**applicationContext.getBean**( StringHelperUtl.firstCharToLower( className ) );

//Next will update the "xyz"  instance to cache and from 2nd time onwards we fetch it from our own cache if our hash key matches.

Note : applicationContext.xml contents and the configuration used to generate the source file are same for above use case.

Let me know if more details are need.

Really appreciate your help and inputs.

Also I could see SPR-17282 with same details but with latest versions.

Right now we are on Java 1.7 version.

[Srikanth249]

Implementation class "XmlWebApplicationContext" for applicationContext.
Generation of Java source,registration and fetching with be done runtime.

[Srikanth249]

Hi,

We tested the same code with other versions as mentioned below, looks like it got introduced in 4.3.0.RELEASE version. We can see time lag difference from 4.2.9 to 4.3.0

4.2.8

Time Difference -> Start : End : Tue Feb 19 23:32:16 PST 2019 --> Tue Feb 19 23:32:17 PST 2019 -> 1Sec

4.2.9

1st Time
Time Difference -> Start : End : Tue Feb 19 20:33:08 PST 2019 --> Tue Feb 19 20:33:09 PST 2019 -> 1Sec

2nd Time
Time Difference -> Start : End : Tue Feb 19 21:24:25 PST 2019 --> Tue Feb 19 21:24:26 PST 2019 -> 1Sec

4.3.0

Time Difference -> Start : End : Tue Feb 19 22:00:05 PST 2019 --> Tue Feb 19 22:03:27 PST 2019 -> 3mins 22Sec

4.3.2

Time Difference -> Start : End : Tue Feb 19 20:58:58 PST 2019 --> Tue Feb 19 21:02:18 PST 2019 -> 2mins 20Sec

4.3.15

Time Difference -> Start : End : Tue Feb 19 22:28:27 PST 2019 --> Tue Feb 19 22:31:48 PST 2019 -> 3mins 21Sec

4.3.16

Time Difference -> Start : End : Tue Feb 19 22:28:27 PST 2019 --> Tue Feb 19 22:31:48 PST 2019 -> 3mins 24Sec

4.3.17

Time Difference -> Start : End : Tue Feb 19 23:18:11 PST 2019 --> Tue Feb 19 23:21:30 PST 2019 -> 3mins 19Sec

[sdeleuze]

Thanks for these additional details, could you check with latest 5.1.5.RELEASE to see what performances you have? How many times are you invoking ApplicationContext.getBean(Class)?

[Srikanth249]

We are on Java7 and tried the latest on 4.3.22. Still performance issue exists as mentioned.

[jhoeller]

Thanks @Srikanth249, that helps a lot for a start. Some additional mechanism introduced in the 4.3 timeframe must severely degrade in case of a large number of beans here. We'll try to sort this out for 4.3.23 and the corresponding 5.0.13 and 5.1.6 releases which are probably also affected.

[Srikanth249]

Thank You @jhoeller, for the update.
One of our customer releases got affected and it would be helpful if you provide the expected release date.

Thanks in Advance.

[jhoeller]

Our next round of releases, including 4.3.23, is scheduled for March 27th. The latest dates can always be found at the https://github.com/spring-projects/spring-framework/milestones page.

For this case, I hope we can fully track down the cause of the regression and sort it out by then.

[Srikanth249]

Hi Juergen, Can we get any intermediate patch or any workaround to resolve this issue, as our new customer go-live and several existing customer upgrades are being impacted and this needs immediate resolution.
Any information is helpful and appreciated.

[jhoeller]

I'm afraid we still don't know the root cause of the performance degradation here. Are you seeing a degradation on first access to a bean (i.e. the type-based resolution algorithm got more expensive) or just on repeated access to the same bean (in which case it's likely that the underlying cache is not being used properly)? Any insight appreciated since we intend to fix this for our March 27th releases still...

As for a workaround, there's only really the use of getBean(String) (as long as you can rely on the names of your target beans) which is much faster in general since it is a straight key-based lookup in a map and doesn't require any type-based matching. Or as suggested in #22537, possibly the use of an external createBean(Class) call which autowires external instances not managed by the bean container.

[Srikanth249]

Issue is coming only on the first access to the bean, from second time onward its coming as expected.

Only by jar upgrade we came across the performance issue, and the same code is present from long time and its the base code for our system, changing the code now as said may cause any other issues to the system and need to perform complete regression.

[Srikanth249]

Hi Juergen,
Can we know in which version this will fix?

[quaff]

@Srikanth249 You should provide a minimum runnable project like AutowirePerformance.zip in #23905

[sajalsingh12]

Can someone assign it to me?

[jhoeller]

At this point, this issue is not about an independent regression anymore but rather to be seen as part of the wider bean type matching performance topic: #22060.