Web container
To route servlet requests from the Web server to the Web containers, a transport queue between the Web server plug-in and each Web container is established. The number of client requests accepted by the container is determined by the Web container thread pool. Connection reuse is another factor that influences the number of concurrent threads that are processed by the Web container.
Thread pool
The Web container maintains a thread pool to process inbound HTTP(S) requests for resources in the container (that is servlets and JSPs). This is a closed queue, since the thread pool is bounded by the maximum thread size.
Tivoli Performance Viewer can help tune the Web container thread pool size settings. Use a standard workload that represents a typical number of incoming client requests, use a fixed number of iterations, and use a standard set of configuration settings. Watch the Percent Maxed and Active Threads counters of the Web container submodule of the Thread Pools module. If the value of the Percent Maxed counter is consistently in the double digits, then the Web container could be a bottleneck and the number of threads should be increased. On the other hand if the number of active threads are significantly lower than the number of threads in the pool, consider lowering the thread pool size for a performance gain.
For Linux systems, the recommended value for the Web container maximum thread pool size used to be 25. However, new Linux kernel versions might support a higher value. The WebSphere performance team is currently working on a list of Linux distributions/kernel versions that support higher values. Please monitor the WebSphere InfoCenter for updates on this.
The Web container thread pool size is configured from the Administrative Console using these steps:
Go to...
Servers | Application Servers | application_server | Web container | Thread Pool
Use the Maximum Size field to configure the maximum pool size. Note that in contrast to the ORB, the Web container only uses threads from the pool, hence a closed queue. The default value is 50.
Save the configuration and restart the affected appserver for the change to take effect.
Checking the Growable Thread Pool box on the Thread Pool Configuration page allows for an automatic increase of the number of threads beyond the maximum size configured for the thread pool. As a result of this, the system can become overloaded because too many threads are allocated.
MaxKeepAliveConnections
The MaxKeepAliveConnections parameter describes the maximum number of concurrent connections to the Web container that are allowed to be kept alive, that is, to be processed in multiple requests. The Web server plug-in keeps connections open to the appserver as long as it can. However, if the value of this property is too small, performance is negatively impacted because the Web server plug-in has to open a new connection for each request instead of sending multiple requests through one connection.
The netstat command utility can help tune the maximum keep-alive connections setting. Use a standard workload that represents a typical number of incoming client requests, use a fixed number of iterations, and use a standard set of configuration settings. Watch the number of connections in the TIME_WAIT state to the appserver port. If the count of TIME_WAITs is consistently in the double digits, it might improve performance to raise the maximum keep-alive connections or maximum keep-alive requests properties (described in MaxKeepAliveRequests). Commands for retrieving the count of TIME_WAITs are shown in Example 19-4. Substitute the port number with the port of the specific application server you want to monitor. Be aware that having both the Web server and application server installed on the same machine would result in a double count of every connection (since the TIME_WAIT state is listed from both the client side and server side by netstat).
Example 19-4 Using netstat to determine the time_wait values
On the Windows platform the chain of commands would be:
netstat -na | find /i "time_wait" | find /c "9080"
On the Unix platform the chain of commands would look like:
netstat -na | grep -i time_wait | grep -c 9080
To configure maximum number of keep-alive connections allowed to the Web container...
Servers | Application Servers | application_servers | Web Container | HTTP Transports
Select the host link for which to configure the max keep-alive connections setting in the host column of the HTTP Transports pane in the workspace.
Select Custom properties in the Additional Properties pane of the workspace.
Click the New button.
Enter MaxKeepAliveConnections in the Name field and an integer value in the Value field (the recommended starting value is 90% of the maximum threads in the Web container thread pool).
Click OK, save the configuration, and restart the affected appserver for the change to take effect.
The value should be at least 90% of the maximum number of threads in the Web container thread pool. If it is 100% of the maximum number of threads in the Web container thread pool, all the threads could be consumed by keep-alive connections leaving no threads available to process new connections.
The appserver might not accept a new connection under a heavy load if there are too many sockets in TIME_WAIT state.
If all client requests are going through the Web server plug-in and there are many TIME_WAIT state sockets for the Web container port, the appserver is closing connections prematurely, which decreases performance. The application server will close the connection from the Web server plug-in, or from any client, for any of the following reasons:
MaxKeepAliveRequests
The MaxKeepAliveRequests is the maximum number of requests allowed on a single keep-alive connection. This parameter can help prevent denial of service attacks when a client tries to hold on to a keep-alive connection. The Web server plug-in keeps connections open to the appserver as long as it can, providing optimum performance.
A good starting value for the maximum number of requests allowed is 100. If the appserver requests are received from the Web server plug-in only, increase this parameter's value. The netstat utility can be used to tune the value of maximum keep-alive requests as described in MaxKeepAliveConnections. If the number of connections in the TIME_WAIT state is too high, consider raising the maximum keep-alive requests setting.
The maximum number of requests allowed is configured from the Administrative Console using these steps:
HTTP transport custom properties
Following is a list of additional custom properties of the HTTP transport provided with the appserver. These custom properties are useful for further tuning measures. Like the previous two, MaxKeepAliveRequests and MaxKeepAliveSessions, these custom properties are not shown in the settings page for an HTTP transport, but have to be set via the Custom properties pane in the same way as described above.
Specifies the maximum number of seconds to wait when trying to read or process data during a request. The default value is 5 seconds.
Specifies the maximum number of seconds to wait when trying to read or write data during a response. The default is 300 seconds.
Specifies the maximum number of outstanding connect requests that the operating system will buffer while it waits for the appserver to accept the connections. If a client attempts to connect when this operating system buffer is full, the connect request will be rejected. The default setting is 511.
Set this value to the number of concurrent connections that you would like to allow. Keep in mind that a single client browser might need to open multiple concurrent connections (perhaps four or five); however, also keep in mind that increasing this value consumes more kernel resources. The value of this property is specific to each transport.
Specifies whether or not to keep connections alive, that is, persistent. The default value is true.
The Web server plug-in keeps connections open to the appserver as long as it can, bounded by the following keep alive parameter settings:
Specifies the maximum number of concurrent keep alive (persistent) connections across all HTTP transports. To make a particular transport close connections after a request, you can set MaxKeepAliveConnections to 0 (zero) or you can set KeepAliveEnabled to false on that transport. The default is 90% of the maximum number of threads in the Web container thread pool (default maximum thread pool size = 50, which means that the default MaxKeepAliveConnections = 45).
Specifies the maximum number of requests which can be processed on a single keep alive connection. This parameter can help prevent denial-of-service attacks when a client tries to hold on to a keep-alive connection. The default is 100 requests.
Specifies the maximum number of seconds to wait for the next request on a keep alive connection.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.