-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix elytron properties perf issues #6358
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I added a comment to further improve the situation.
@Override | ||
public Provider[] get() { | ||
return new Provider[] { new WildFlyElytronProvider() }; | ||
return providers; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you can make the whole supplier static and reuse it at both locations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Also, can you check in the other security implementations that we don't have this pattern? |
66130aa
to
2207f88
Compare
@gsmet I add the same performance optimization to the JDBC implementation. OAuth2 and OIDC didn't suffers from the same issue. |
2207f88
to
ba2f7f8
Compare
@gsmet I also review the LDAP and JPA security extensions currently under review, LDAP has the same issue (I add a review comment), JPA doesn't seems to have it (not 100% sure as it's a complex extension and I just have a quick look). |
Merged, thanks! |
During some performance testing, I discover, thanks to profiler CPU flamegraph, that the Elytron Properties implementation uses a lot of CPU cycles to create the
WilldFlyElytronProvider
.It apears that the security provider supplier is called on each request calls, and triggers the creation of a new
WilldFlyElytronProvider
.Creating a unique
WilldFlyElytronProvider
and returing it from the supplier instead of creating it each time fix the issue.