-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
Performance bottlenecks while creating scoped bean instances #30883
Comments
I created a pull request to address three of the four stacks listed in this issue, which represent 95% of the problem and are sufficient to satisfy this issue. |
We cache a |
I've also included a minor Last but not least, the |
This is in 5.3.x as well now, feel to give it a try! Should be straightforward enough to patch 5.2.x with it but I strongly recommend an upgrade to 5.3.30 (and trying a 5.3.30 build snapshot for the time being). FWIW the 5.2.x line has reached its end of open source support a while ago already and will reach its ultimate end of life by the end of this year. |
Aside from some alignment in related classes, the core part of the change is in |
Thank you so much!!! The relevant applications are planning the 5.3 upgrade by October, but I'll do some 5.2.x testing this week and get back to you ASAP. |
I confirmed ConstructorResolver works on 5.2. Won't be able to test 5.3 for at least another month but will raise a new, linked issue if something comes up. Thank you very much! |
Affects: 5.2+
My organization has multiple high-traffic, customer-facing applications that create many beans per request. The individual creations are fast enough but in aggregate these beans contribute noticeably to the request's critical path latency, as well as the per-request cpu. The key portion of the stack trace is:
Eventual leaf nodes of the call graph are:
java.lang.Class.forName0
java.lang.reflect.Constructor.getParameterAnnotations
java.lang.reflect.Method.getParameterAnnotations
org.springframework.core.annotation.AnnotationUtils.getValue
Annotations and classes don't change during runtime, yet they are repeatedly processed.
Solution
Some level of caching is appropriate, either multiple caches (one per leaf) or a single larger one around
ConstructorResolver.resolvePreparedArguments
. Multiple specific caches seems preferable because of lower contention and simpler keys.Supporting Data
Below are further, detailed stack traces that illustrate the path from ConstructorResolver.resolvePreparedArguments to the leaf nodes.
The text was updated successfully, but these errors were encountered: