12.4.1 Performance tuning
In Application Server version 11 and Developer version 11, the following viewpoints were changed from the viewpoints of performance tuning of the J2EE application execution platform:
-
Optimization of the number of concurrent executions
-
Timeout setting
- Organization of this subsection
(1) Optimization of the number of concurrent executions
In Application Server version 9 or earlier and Developer version 9 or earlier, a request processing thread of the Web container was always assigned to a connection and the request processing thread was occupied until the response body was sent to the client.
Application Server version 11 or later and Developer version 11 or later support the standard specifications that are premised on non-blocking I/O such as asynchronous servlets of Servlet 3.0, asynchronous I/O APIs of Servlet 3.1, and WebSocket. For this reason, management of the connections that receive requests and the threads that process received requests are separated to enable a connection to use multiple processing threads and enable processing that receives a request and processing that sends a response to be processed by separate threads.
As a result, Application Server version 11 and Developer version 11 have a different approach to control of the number of concurrent executions from that of version 9 or earlier. The following describes the differences in the points to set control of the number of concurrent executions for each Web server configuration.
(a) When migrating from the Web server integration configuration using the redirector
The redirector functionality used in Application Server version 9 or earlier and Developer version 9 or earlier used permanent connections to connect the Web server and the Web container, and occupied a request processing thread for each connection on the Web container. For this reason, the number of threads to be generated is always the same as the maximum number of connections that can be concurrently connected. In addition, by controlling the number of concurrently executing threads to control the threads that could be concurrently executed among the generated threads, you could suppress performance degradation and resource depletion. The following figure shows the mechanism of controlling the number of threads in Application Server version 9 and Developer version 9.
|
|
![[Figure]](GRAPHICS/ZU120300.GIF)
With the NIO HTTP server functionality of Application Server version 11 and Developer version 11, even if permanent connections are used to connect the Web server and the Web container, the request processing threads on the Web container are not occupied by the connections. Each time the Web container detects the reception of data, it assigns a thread from the thread pool. In addition, by controlling the number of concurrently executing threads to control the threads that can be concurrently executed among the threads assigned to requests for processing a request of the servlet, you can suppress performance degradation and resource depletion in the same way as Application Server version 9 and Developer version 9. The following figure shows the mechanism of controlling the number of threads in Application Server version 11 and Developer version 11.
|
|
![[Figure]](GRAPHICS/ZU120400.GIF)
The NIO HTTP server functionality allows you to define the number of threads to be generated in advance in the thread pool when the J2EE server starts and the maximum number of threads to be dynamically generated. The following table describes the recommended values set for the number of threads when you migrate from Application Server version 9 and Developer version 9 in the Web server integration configuration. Note, however, that this does not apply when you use the WebSocket functionality. For details, see (c) Notes when increasing the maximum number of concurrent connections to use the WebSocket functionality.
|
Parameter of the setting destination NIO HTTP server |
Recommended setting value |
|
|---|---|---|
|
When using only the functionality up to Application Server version 9 and Developer version 9 |
When using asynchronous processing supported in Application Server version 11 and Developer version 11 |
|
|
webserver.connector.nio_http.max_threads |
The same value as webserver.connector.ajp13.max_threads |
Value of webserver.connector.ajp13.max_threads + Maximum number of concurrent executions of asynchronous processing#1 to be concurrently executed in excess of the number of connections |
|
webserver.connector.nio_http.min_threads |
The same value as webserver.connector.ajp13.max_threads |
|
|
webserver.connector.nio_http.max_connections |
Total number of connections to the J2EE server#2 |
|
- #1
-
Asynchronous processing to be concurrently executed in excess of the number of connections includes the following:
-
Invoking the start method of javax.servlet.AsyncContext of Servlet 3.0
-
Invoking the sendBinary method, the sendObject method, and the sendText method of the javax.websocket.RemoteEndpoint.Async interface of WebSocket
-
- #2
-
Total number of connections to the J2EE server is the sum of the number of connections to the NIO HTTP server on the J2EE server. If multiple processes connect to the J2EE server, set the sum of the maximum number of connections from each process.
For details on the maximum number of connections from the reverse proxy of the Cosminexus HTTP Server to the J2EE server, see 4.7.4(5) Points to be noted for performance in the uCosminexus Application Server HTTP Server User Guide.
(b) When migrating from the in-process HTTP server configuration
The in-process HTTP server functionality used in Application Server version 9 or earlier and Developer version 9 or earlier assigned a thread generated in advance in the thread pool to each connection each time a connection request was sent from the client, and occupied that thread until the connection with the client is disconnected. In addition, by controlling the number of concurrently executing threads to control the threads that can be concurrently executed among the generated threads, you could suppress performance degradation and resource depletion.
In the NIO HTTP server functionality of Application Server version 11 and Developer version 11, the request processing thread on the Web container is not occupied by the connection, and the Web container assigns a thread from the thread pool each time it detects the reception of data. In addition, by controlling the number of concurrently executing threads to control the threads that can be concurrently executed among the threads assigned to the requests for processing a request of the servlet, you can suppress performance degradation and resource depletion in the same way as Application Server version 9 and Developer version 9.
The NIO HTTP server functionality allows you to define the number of threads to be generated in advance in the thread pool when the J2EE server starts and the maximum number of threads to be dynamically generated. The following table describes the recommended values set for the number of threads when you migrate from Application Server version 9 and Developer version 9 in the in-process HTTP server configuration. Note, however, that this does not apply when you use the WebSocket functionality. For details, see (c) Notes when increasing the maximum number of concurrent connections to use the WebSocket functionality.
|
Parameter of the setting destination NIO HTTP server |
Recommended setting value in Application Server version 11 and Developer version 11 |
|
|---|---|---|
|
When using only the functionality up to Application Server version 9 and Developer version 9 |
When using asynchronous processing supported in Application Server version 11 and Developer version 11 |
|
|
webserver.connector.nio_http.max_threads |
The same value as webserver.connector.inprocess_http.max_connections |
Value of webserver.connector.inprocess_http.max_connections + Maximum number of concurrent executions of asynchronous processing# to be concurrently executed in excess of the number of connections |
|
webserver.connector.nio_http.min_threads |
The smallest value of webserver.connector.inprocess_http.max_connections, webserver.connector.inprocess_http.max_spare_threads, and webserver.connector.inprocess_http.init_threads |
|
|
webserver.connector.nio_http.max_connections |
The same value as webserver.connector.inprocess_http.max_connections |
|
- #
-
Asynchronous processing to be concurrently executed in excess of the number of connections includes the following:
-
Invoking the start method of javax.servlet.AsyncContext of Servlet 3.0
-
Invoking the sendBinary method, the sendObject method, and the sendText method of the javax.websocket.RemoteEndpoint.Async interface of WebSocket
-
(c) Notes when increasing the maximum number of concurrent connections to use the WebSocket functionality
For the NIO HTTP server functionality of Application Server version 11 and Developer version 11, the number of threads and the maximum number of concurrent connections do not necessarily have to be the same value. Even if the number of threads is smaller than the number of concurrent connections, no pending processing will occur if the maximum number of concurrently executing threads, which concurrently execute processing to receive data, is within the maximum number of threads. In addition, even if pending processing occurs because no thread can be assigned, the processing is queued in the infinite-length pending queue and the processing to receive data will resume when a thread becomes free.
If you use the WebSocket functionality added in Application Server version 11 and Developer version 11, you might need to increase the maximum number of concurrent connections to maintain connections with many WebSocket clients for a long time. In Application Server version 9 or earlier and Developer version 9 or earlier, for both Cosminexus HTTP Server and the in-process HTTP server, the maximum number of concurrent connections was limited to 1024. However, in Application Server version 11 and Developer version 11, the upper limit was increased in consideration of WebSocket support.
However, if you increase the maximum number of threads for the NIO HTTP server to match the maximum number of concurrent connections, the memory usage also increases in proportion to the number of threads. In addition, the number of threads that can be generated by a process is limited by the OS. If the memory capacity that can be secured for the minimum number of threads or the upper limit of the number of threads of the OS is insufficient, OutOfMemoryError might occur during the processing to start the J2EE server, causing the J2EE server to fail to start. If the memory capacity that can be secured for the maximum number of threads or the upper limit of the number of threads of the OS is insufficient, OutOfMemoryError might occur during the processing to receive requests, causing the J2EE server process to go down.
If you want to increase the minimum or maximum number of threads for the NIO HTTP server, appropriately re-estimate the memory size (physical memory size, the value specified for -Xmx of the J2EE server process) as well.
For details about how to estimate the maximum number of threads, see 5.2.1 Estimating the resources used by J2EE server in the uCosminexus Application Server System Design Guide. For details about memory usage, see 5.3.1 Estimating virtual memory usage of the J2EE server in the uCosminexus Application Server System Design Guide.
(2) Timeout setting
In Application Server version 11 or later and Developer version 11 or later, the locations where a timeout occurs and the parameter for which the timeout value is set are different from those in Application Server version 9 or earlier and Developer version 9 or earlier. The following describes the differences in the timeout setting points for each Web server configuration.
(a) When migrating from the Web server integration configuration using the redirector
In Application Server version 11 and Developer version 11, the redirector module (mod_jk) changes to the proxy module (mod_proxy) and the request receiver on the Web container changes to the NIO HTTP server.
For this reason, the timeouts set for the redirector and the Web container in Application Server version 9 and Developer version 9 change to the timeouts set for the reverse proxy and the NIO HTTP server in Application Server version 11 and Developer version 11.
The following figure shows the points for which a timeout can be set in Application Server version 9 and Developer version 9.
|
|
![[Figure]](GRAPHICS/ZU120500.GIF)
The following figure shows the points for which a timeout can be set in Application Server version 11 and Developer version 11.
|
|
![[Figure]](GRAPHICS/ZU120600.GIF)
The following table describes the differences for each point that needs to be migrated from Application Server version 9 and Developer version 9 to Application Server version 11 and Developer version 11.
|
Point |
Timeout type |
|
|---|---|---|
|
Application Server version 9 and Developer version 9 |
Application Server version 11 and Developer version 11 |
|
|
2 |
A timeout for establishing a connection to the Web container, which is set on the redirector.
|
A timeout for establishing a connection to the Web container (NIO HTTP server), which is set on the reverse proxy.
|
|
3 |
A timeout for sending the request header and the request body to the Web container, which is set on the redirector.
|
A timeout for sending the request header and the request body to the Web container (NIO HTTP server), which is set on the reverse proxy.
|
|
4 |
A timeout for receiving data from the Web container, which is set on the redirector.
|
A timeout for receiving data from the Web container (NIO HTTP server), which is set on the reverse proxy.
|
|
5 |
A timeout for receiving data from the redirector, which is set on the Web container.
|
A timeout for receiving data from the reverse proxy, which is set on the Web container (NIO HTTP server).
|
|
13 |
A timeout for sending the response to the redirector, which is set on the Web container.
|
A timeout for sending data to the reverse proxy, which is set on the Web container (NIO HTTP server).
|
(b) When migrating from the in-process HTTP server configuration
In Application Server version 11 and Developer version 11, the in-process HTTP server is replaced with the NIO HTTP server.
For this reason, the timeouts set for the in-process HTTP server in Application Server version 9 and Developer version 9 change to the timeouts set for the NIO HTTP server in Application Server version 11 and Developer version 11.
The following figure shows the points for which a timeout can be set.
|
|
![[Figure]](GRAPHICS/ZU120700.GIF)
The following table describes the differences for each point that needs to be migrated from Application Server version 9 and Developer version 9 to Application Server version 11 and Developer version 11.
|
Point |
Timeout type |
|
|---|---|---|
|
Application Server version 9 and Developer version 9 |
Application Server version 11 and Developer version 11 |
|
|
5 |
A timeout for receiving a request from the client, which is set on the Web container.
|
A timeout for receiving data from the client, which is set on the NIO HTTP server.
|
|
13 |
A timeout for sending the response to the client, which is set on the Web container.
|
A timeout for sending data to the client, which is set on the NIO HTTP server.
|