Tuning Web server thread pool
There are a large set of tuning aspects which ultimately influence the performance of the web server. One of the most important factors is tuning the HTTP Connector thread pool settings to more closely match the web request load you have. This is difficult to do, but is very important to get right for best performance.
The amount of threads which are allowed by the web server are referenced through the executor attribute:
<subsystem xmlns="urn:jboss:domain:web:1.0"> <connector enable-lookups="false" enabled="true" executor="http-executor" max-connections="200" max-post-size="2048" max-save-post-size="4096" name="http" protocol="HTTP/1.1" proxy-name="proxy" proxy-port="8081" redirect-port="8443" scheme="http" secure="false" socket-binding="http" /> . . . </subsystem>
Then, within the threads subsystem, you can define the number of threads which will be used by the pool, along with the other thread attributes (see Chapter 2, Configuring the Application Server, for more details about the thread subsystem):
<subsystem xmlns="urn:jboss:domain:threads:1.0"> <bounded-queue-thread-pool name="http-executor" blocking="true"> <core-threads count="10" per-cpu="20" /> <queue-length count="10" per-cpu="20" /> <max-threads count="10" per-cpu="20" /> <keepalive-time time="10" unit="seconds" /> </bounded-queue-thread-pool> </subsystem>
The most important Connector attributes are defined into the core-threads and max-threads. Setting these values too low means that you may not have enough threads to handle all of the requests, in which case, requests have to sit idle for some time without being handled until another request thread is freed up. Too low of a value also means that JBoss Web server will be unable to take advantage of your server machine's hardware.
On the other hand, be careful before increasing these thread counts blindly. By increasing the thread count too much, you will:
• Consume a good chunk of memory
• Your system will spend too much time-context switching
You should, at first, investigate if it's rather a problem of individual requests taking too long. Are your threads returning to the pool? If, for example, database connections are not released, threads pile up waiting to obtain a database connection thereby making it impossible to process additional requests.
In such a scenario, simply adding more thread will make things even worse by introducing a greater stress on the CPU and on the garbage collector. You can discover this kind of problem by simply taking a thread dump in your application to find out where your web server threads are stuck. For example, in this picture, taken from JConsole threads tab, you can see how an idle thread should look like, by looking at its stack trace:
On the other hand, the following HTTP thread is busy at doing input/output operations which could mean, for example, the web server is acquiring data from an external resource.
The above snapshots gives you also a clue on how you can monitor the number of web server running threads. Just fill in the executor name (http-executor) in the lower textfield, and you will have a filtered list of all your web server threads.