---

From: "Benjamin Browning" <bbrowning@redhat.com>
To: "jboss-as7-dev@lists.jboss.org Development" <jboss-as7-dev@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@redhat.com>
> Red Hat Inc
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev