Skip to content

getBean(Class) lookup performance degredation on upgrade #22425

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Srikanth249 opened this issue Feb 18, 2019 · 16 comments
Closed

getBean(Class) lookup performance degredation on upgrade #22425

Srikanth249 opened this issue Feb 18, 2019 · 16 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue type: regression A bug that is also a regression

Comments

@Srikanth249
Copy link

Srikanth249 commented Feb 18, 2019

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
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Feb 18, 2019
@sdeleuze
Copy link
Contributor

Any chance you could provide a repro project?

@Srikanth249
Copy link
Author

Srikanth249 commented Feb 18, 2019

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.

@jhoeller jhoeller self-assigned this Feb 18, 2019
@Srikanth249
Copy link
Author

Srikanth249 commented Feb 18, 2019

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

@Srikanth249
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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

@jhoeller
Copy link
Contributor

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.

@jhoeller jhoeller added type: regression A bug that is also a regression and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Feb 20, 2019
@jhoeller jhoeller added this to the 4.3.23 milestone Feb 20, 2019
@Srikanth249
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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.

@sbrannen sbrannen added the in: core Issues in core modules (aop, beans, core, context, expression) label Mar 7, 2019
@jhoeller
Copy link
Contributor

jhoeller commented Mar 7, 2019

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
Copy link
Author

Srikanth249 commented Mar 12, 2019

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.

@jhoeller jhoeller modified the milestones: 4.3.23, 5.2 RC1 Mar 26, 2019
@jhoeller jhoeller modified the milestones: 5.2 M3, 5.2 RC1 May 7, 2019
@jhoeller jhoeller modified the milestones: 5.2 RC1, 5.2 RC2 Jul 10, 2019
@Srikanth249
Copy link
Author

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

@jhoeller jhoeller modified the milestones: 5.2 RC2, 5.2 GA Sep 2, 2019
@jhoeller jhoeller modified the milestones: 5.2 GA, 5.3 M1 Sep 23, 2019
@quaff
Copy link
Contributor

quaff commented Nov 5, 2019

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

@sajalsingh12
Copy link

Can someone assign it to me?

@jhoeller jhoeller modified the milestones: 5.3 M1, 5.3 M2 May 12, 2020
@jhoeller jhoeller modified the milestones: 5.3 M2, 5.3 RC1 Jun 23, 2020
@jhoeller jhoeller modified the milestones: 5.3 RC1, 5.3 RC2 Aug 24, 2020
@jhoeller jhoeller modified the milestones: 5.3 RC2, 5.x Backlog Sep 14, 2020
@jhoeller jhoeller modified the milestones: 5.x, General Backlog Nov 1, 2021
@jhoeller jhoeller modified the milestones: General Backlog, 6.x Backlog Jul 12, 2023
@jhoeller
Copy link
Contributor

jhoeller commented Aug 4, 2023

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.

@jhoeller jhoeller closed this as completed Aug 4, 2023
@jhoeller jhoeller added the status: duplicate A duplicate of another issue label Aug 4, 2023
@jhoeller jhoeller removed this from the 6.x Backlog milestone Aug 4, 2023
@sbrannen sbrannen closed this as not planned Won't fix, can't repro, duplicate, stale Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: duplicate A duplicate of another issue type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

7 participants