[jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads

[Andrig Miller]

----- Original Message -----

> From: "Benjamin Browning" <bbrowning at redhat.com>
> To: "jboss-as7-dev at lists.jboss.org Development"
> <jboss-as7-dev at lists.jboss.org>
> Sent: Friday, October 21, 2011 8:13:43 AM
> Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web
> HTTP Threads

> On Oct 21, 2011, at 8:43 AM, Remy Maucherat wrote:

> > On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote:
> >> I agree with everything Andy said and absolutely needed to be able
> >> to
> >> set maxThreads in our TorqueBox benchmarks. There may be some
> >> hypothetical reason I shouldn't need to set maxThreads but in
> >> practice
> >> the performance before and after was night and day once a hit a
> >> high
> >> enough concurrent client load. The defaults of 512 * # of CPUs was
> >> way
> >> too high - 4096 http threads on my 8 CPU benchmark server kills
> >> performance and eats up way too many resources.
> >
> > If you want to run serious benchmarks and tune things, you should
> > be
> > aware of how the server works, and what are the possibilities to
> > solve
> > the problem.
> >
> > The issue with reducing the amount of threads with the default
> > java.io
> > connector (which is used unless the native libraries are installed)
> > is
> > that it will, in most case, use a lot of its threads to do
> > keepalive.
> > Keepalive is usually very important for real servers to give good
> > user
> > experience, and also can help performance a lot. However, this is a
> > problem since, when running a benchmark with a specific client,
> > keepalive might not be used, or at least much less, and all threads
> > could actually be in the application, so 512 * n becomes far too
> > high.
> > The problem goes away with the native libraries, since there is an
> > efficient way to handle keepalive, and all threads will be
> > dedicated to
> > actually running the application. The default for the native
> > connectors
> > is 32 * n threads. With native, a high number of threads is
> > actually
> > directly detrimental to performance, since it has a lot of
> > asynchronous
> > capabilities and needs a sync in one location to avoid crashing.

> Thanks for the detailed explanation on keepalives and the defaults.

In terms of keep alives, I had opened a JIRA to add the maxKeepAlive parameter to the schema and expose that for tuning. Is there an issue you have with exposing that? It's another key tuning parameter for benchmarking. 

Andy 

> >
> > You have solutions, even with the java.io connector:
> > - Use an executor. This has all the configuration options you could
> > like, and the performance difference may not be measurable
> > depending on
> > the application.
> > - Use a semaphore valve or filter, which will only allow a certain
> > amount of threads to concurrently enter specific parts of your
> > application. This allows much more fine tuning and could be a good
> > strategy.
> >
> > As a compromise, I will propagate max-connections to maxThreads for
> > the
> > java.io connector. This shouldn't hurt too much, and this
> > corresponds
> > relatively well to the concept of connection count after all.

> Thanks!

> >
> > --
> > Remy Maucherat <rmaucher at redhat.com>
> > Red Hat Inc
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111021/38b731e7/attachment.html