[security-dev] Picketbox performance improvements
sdouglas at redhat.com
Thu Sep 5 05:41:07 EDT 2013
Oops, just realised I missed that the same thing was happening with the SecurityContextUtil class.
With this patch, and my recently merged SecurityContextAssociationValve patch, I have seen a >20% increase in performance of an empty web application (28k req/sec vs 23k req/sec).
----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: security-dev at lists.jboss.org, "Andrig Miller" <anmiller at redhat.com>
> Sent: Wednesday, 4 September, 2013 3:47:47 PM
> Subject: Re: [security-dev] Picketbox performance improvements
> Hi Stuart,
> it will be a couple of days to upgrade. There are other fixes going
> into the upgrade.
> On 09/04/2013 04:31 AM, Stuart Douglas wrote:
> > Hi,
> > I have been benchmarking Wildfly upstream, and with the exception of the
> > Weld listener (that I am about to try and fix), I am seeing the creation
> > of the security context as by far the most expensive part of the web
> > request chain.
> > Firstly a bit about the tests, basically it is possible to run Undertow in
> > pipelining mode, where if you send it pipelined HTTP requests it will
> > buffer the responses and batch them. This is not super useful in practice,
> > but what it does allow me to do is basically take most of the IO component
> > out of a web request, and just look at which bits of the web request chain
> > are consuming the most CPU.
> > The issues I am seeing are:
> > - Some unnecessary AccessController.doPrivilidged calls
> > - A reflection call on every request to lookup the constructor of the
> > security context class
> > I have provided a patch to address both of these, by adding a guard around
> > the AccessController calls, and by caching the constructor used for the
> > default security context class. I think it may even be worthwhile taking
> > this one step further, and using generated bytecode to create the class.
> > Normally I would consider this overkill but security context creation
> > happens on every request, so if we are serious about performance we should
> > be trying to make it as cheap as possible.
> > To give you an idea of how much this affects the total cost of the Servlet
> > pipeline:
> > Current WF upstream (without Weld): 134k req/sec
> > After removing the AccessController calls: 158k req/sec
> > Adding constructor caching: 171k req/sec
> > Note that the speedup will not be as big for more realistic workloads,
> > however it will still be significant.
> > Stuart
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9116 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/security-dev/attachments/20130905/b6b00162/attachment.bin
More information about the security-dev