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

[Benjamin Browning]

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. 

> 
> 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