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

[Remy Maucherat]

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.

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.

-- 
Remy Maucherat <rmaucher at redhat.com>
Red Hat Inc