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).
Stuart
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>
Cc: security-dev(a)lists.jboss.org, "Andrig Miller" <anmiller(a)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.
Regards,
Anil
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
>