17.3.1 Controlling the number of request-processing threads in a Web server
In the case of Web front-end systems, the request-processing thread created by the Web 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 section describes the purpose of controlling the number of request-processing threads in Web servers, and the guidelines for tuning.
This section also describes tuning methods if you use an in-process HTTP server.
- Reference note
-
When Cosminexus HTTP Server is used for Web server integration, similar tuning can be done for the settings of Cosminexus HTTP Server. For details, see the manual Cosminexus HTTP Server.
In order to build a system using the Smart Composer functionality, you can use abstract parameters for setting the number of request-processing threads in the Web server. An abstract parameter means several mutually related parameters merged into a single parameter. Use an abstract parameter to define the settings for the number of request-processing threads of Web server along with the related parameters such as the number of concurrent executions. For details on abstract parameters, see Appendix I. Abstract parameters available with the Smart Composer Functionality (in V9 compatibility mode) in the manual uCosminexus Application Server Command Reference 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.
When you use an in-process HTTP server, you can generate and pool the request-processing threads in batch when the J2EE server is started, and can use this pool in the event of a processing request from the 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 (back log) of TCP/IP, when the maximum number of connections is exceeded
-
Maximum and minimum number of spare threads
-
Choosing whether or not to maintain the number of request-processing threads generated when the J2EE server is started
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 spare threads, you can promptly handle a sudden increase in the number of accesses from the client, without a decline in the processing performance. However, if you pool a large number of spare threads, many resources will be consumed. Therefore, be careful when setting the appropriate number of pooled spare threads, after estimating the presumed sudden increase in the number of accesses.
-
If a fixed number of request-processing threads are secured, and you want to control the increase and decrease in the number of request-processing threads over and above the fixed number by specifying a maximum number and minimum number, specify the settings for maintaining the number of request-processing threads generated when the J2EE server is started. By doing this, you can handle an increase or decrease in the number of the request-processing threads during peak access from the client, when the minimum number of request-processing threads desired for the system is secured. The number of request-processing threads generated when the J2EE server is started will be maintained even when the number of unused request-processing threads exceeds the maximum number of spare threads.
-
If you want to keep on pooling the threads that are created, without deleting them, set up the maximum number of spare threads to a value same as the maximum number of connections to the Web client.
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 17.3.2 Controlling the number of concurrent executions of a Web application.