Performance Improvement in WSSConfig
------------------------------------
Key: WSS-232
URL: https://issues.apache.org/jira/browse/WSS-232
Project: WSS4J
Issue Type: Improvement
Components: WSS4J Core
Affects Versions: 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8,
1.5.9, 1.6
Environment: Jetty
Reporter: Mario Siegenthaler
Assignee: Ruchith Udayanga Fernando
When I profiled one of our webservices that uses SAML I noticed, that about
half the CPU-time per call gets spent inside
WSSConfig.getProcessor -> Loader.loadClass -> ClassLoader.loadClass
The application server I was running on is Jetty 6 (might have some impact on
the performance of classloading, since it's done with the Webapp-Classloader).
When I reviewed the code I noticed that all the actions and processors inside
WSSConfig are held in a Map with ID -> [either classname or instance). All the
default processors/actions are as Strings (classnames). Most of the processors
have to be instantated per invocation, so I couldn't switch from classnames to
instances.
I propose to add a third value-variant to the maps: Classes. The included
patch contains the changes to WSSConfig. The central parts are inside the
static initialization (I added a helper method to shorten initializer) and in
the #getProcessor and #getAction methods (a third if-instanceof-part). I
retained the dynamic lookup of the opensaml classes.
The patch brings a massive performance enhancement, at least in the
jetty-environment (I didn't test other application server) due to not looking
up the classes on every invocation. The CPU-time of the wss4j library went from
~50% down to 2%.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]