JBossAS7 Performance Tuning (III)

Optimize the Web server Thread Pool

There are also many areas that need optimization that ultimately affect the performance of the Web server. One of the most important factors is to optimize the HTTP thread pool settings to match the load of web requests. This is actually very difficult to achieve, but you can achieve the best performance through optimization.

The number of web Server threads is set 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, in the thread sub-system, you can define the number of threads in the pool to be used, along with other thread attributes (See Chapter 2nd to configure the application server for details about the thread sub-system ):

<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 = "10" unit = "seconds"/> </Bounded-queue-thread-pool> </Subsystem>

The most important property of a connector isCore-threadsAndMax-threadsThese values are set too low and may not have enough threads to process all requests. In this case, the request is not processed and must wait for a while until another request thread is released. A low value also means that the JBoss Web server cannot take full advantage of the server hardware.

On the other hand, be careful to set the number of these threads. setting the number of threads too high will cause:
? A large amount of memory is consumed;
? The system will consume more time for context switching.

First, you should check whether there are individual requests that take a long time and whether the thread is returned to the pool? In this case, the possible cause is that the database connection is not released, and the thread waits in queue to obtain a database connection, so that other requests cannot be processed.

In this case, simply adding more threads will consume more CPU and GC more frequently, making things worse. In the application, you can take a simple thread dump to find out where the web server thread is blocked. For example, in this imageJConsoleIn the thread tab, by observing its stack trace, you can see that it looks similar to the followingIdle thread(Idle thread):

On the other hand, the following HTTP thread is busy with input/output operations, probably because, for example, the Web server is retrieving data from external resources.

 

The preceding snapshot guides you how to monitor the running threads on the Web server. You only need to enter the executor name (http-executor) in the bottom text box ), the list of all Web server threads is displayed.