In the following example, acceptor threads are increased, and keep-alive connections are reduced:
In magnus.conf: MaxKeepAliveConnections 0 RqThrottle 128 RcvBufSize 8192 In server.xml: <SERVER legacyls="ls1"> <LS id="ls1" ip="0.0.0.0" port="8080" security="off" blocking="no" acceptorthreads="2" </SERVER>
HTTP/1.0-style workloads would have many connections established and terminated.
If users are experiencing connection timeouts from a browser to Sun Java System Web Server when the server is heavily loaded, you can increase the size of the HTTP listener backlog queue by setting the ListenQ parameter in the magnus.conf file to:
ListenQ 8192
The ListenQ parameter specifies the maximum number of pending connections on a listen socket. Connections that time out on a listen socket whose backlog queue is full will fail.
In general, it is a tradeoff between throughput and latency while tuning server persistent connection handling. The KeepAliveQueryQuery* directives (KeepAliveQueryMeanTime and KeepAliveQueryMaxSleepTime) control latency. Lowering the values of these directives is intended to lower latency on lightly loaded systems (for example, reduce page load times). Increasing the values of these directives is intended to raise aggregate throughput on heavily loaded systems (for example, increase the number of requests per second the server can handle). However, if there's too much latency and too few clients, aggregate throughput will suffer as the server sits idle unnecessarily. As a result, the general keep-alive subsystem tuning rules at a particular load are as follows:
If there's idle CPU time, decrease KeepAliveQueryMeanTime and/or KeepAliveQueryMaxSleepTime.
If there's no idle CPU time, increase KeepAliveQueryMeanTime and/or KeepAliveQueryMaxSleepTime.
For more information about these directives, seeKeep-Alive Subsystem Tuning
Also, chunked encoding could affect the performance for HTTP/1.1 workload. Tuning the response buffer size could positively affect the performance. A higher OutputStreamSize for a plugin would result in sending Content-length: header, instead of chunking the response.