8.3.3 Controlling the number of request-processing threads
In the case of Web front-end systems, the request-processing thread created by the Application server processes the requests from clients like the Web browser. The processing efficiency can be improved by appropriately controlling the number of request-processing threads.
This subsection describes the purpose of controlling the number of request-processing threads in Application servers, and the guidelines for tuning.
This subsection specifically describes how to tune the number of request-processing threads created by the Web container running on the J2EE server.
- Reference note
-
When using the HTTP Server as a reverse proxy deployed at the front end of the J2EE server, you can accomplish the same tuning in the settings of the HTTP Server. For details, see the manual uCosminexus Application Server HTTP Server User Guide.
- Organization of this subsection
(1) Purpose of controlling the number of request-processing threads
The performance can be improved by tuning the number of request-processing threads according to the quality of the host on which the J2EE server is running, and according to the status of access from the client.
The process of generating request-processing threads puts a heavy load on the system. By generating and pooling the request-processing threads beforehand, you can reduce the load for a processing request from the client, such as a Web browser and can increase the processing performance.
In the Web container, you can generate and pool the request-processing threads as a batch at startup of the J2EE server, and use this pool to fulfil processing requests from a client such as a Web browser. This leads to an improvement in the processing performance when a processing request is received. By monitoring the number of pooled threads, you can generate additional threads when the number of pooled threads becomes less, and can secure these threads in the pool.
However, if you pool a large number of unused threads, it will lead to unnecessary consumption of resources. Therefore, depending on the processing contents of the system, you must appropriately control the number of request-processing threads to be pooled, and delete the unnecessary threads, if required.
When controlling the request-processing threads, set up appropriate values in the parameters by considering the above.
(2) Guidelines for setup
When controlling the number of request-processing threads, you can tune using the following parameters:
-
Number of request-processing threads generated when the J2EE server is started
-
Maximum number of connections to the Web client (number of request-processing threads)
-
Maximum value of the Listen queue (backlog) of TCP/IP, when the maximum number of connections is exceeded
-
Maximum number of request-processing threads
Make a note of the following points when setting up these parameters:
-
Depending on the contents of the service to be provided, a large number of requests must be processed immediately after the J2EE server is started. In such a case, set up a large value in the number of the request-processing threads to be generated when the J2EE server is started.
-
If you increase the maximum number of request-processing threads, you can immediately accommodate sudden increases in client access without a decline in processing performance. However, if you pool a large number of threads, many resources will be consumed. Therefore, be careful when setting the appropriate number of pooled threads, after estimating the presumed sudden increase in the number of accesses.
-
If you want to keep pooling threads rather than deleting them, set the maximum number of request-processing threads to the same value as the minimum number of request-processing threads.
Apart from the above, consider the relationship with the number of concurrently executed threads of the Web application. For details about the number of concurrently executed threads of a Web application, see 8.3.4 Controlling the number of concurrent executions of a Web application.