Sun Java System Web Proxy Server 4.0.11 Performance Tuning, Sizing, and Scaling Guide

Keep-Alive Information

This section provides information about the server’s HTTP-level keep-alive system.

Note –

The name keep alive should not be confused with TCP keep-alives. Also, note that the name keep-alive was changed to PersistentConnections in HTTP 1.1, but Proxy Server continues to refer to these connections as keep-alive connections. Most modern browsers request a web page from the server through persistent connections with the web server. The connection is kept alive even after processing a request, so that it will be easier to process a similar request.

The following example shows the keep-alive statistics displayed by perfdump:

KeepAliveCount        198/200
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     56844280
KeepAliveTimeouts     365589
KeepAliveTimeout      10 seconds

The following table shows the keep-alive statistics displayed in the Admin Console:

Table 2–2 Keep-Alive Statistics

Number of Connections Processed 

Total Number of Connections Added 


Maximum Connection Size 


Number of Connections Flushed 

Number of Connections Refused 


Number of Idle Connections Closed 


Connection Timeout 


Both HTTP 1.0 and HTTP 1.1 support the ability to send multiple requests across a single HTTP session. A proxy server can receive hundreds of new HTTP requests per second. If every request is allowed to keep the connection open indefinitely, the server can become overloaded with connections. On UNIX and Linux systems, this can lead to a file table overflow very easily.

To resolve this problem, the server maintains a counter for the maximum number of waiting keep-alive connections. A waiting keep-alive connection has fully completed processing the previous request, and is now waiting for a new request to arrive on the same connection. If the server has more than the maximum waiting connections open when a new connection waits for a keep-alive request, the server closes the oldest connection. This algorithm keeps an upper bound on the number of open waiting keep-alive connections that the server can maintain.

Sun Java System Web Proxy Server does not always honor a keep-alive request from a client. The following conditions cause the server to close a connection, even if the client has requested a keep-alive connection:

The keep-alive subsystem in Proxy Server is designed to be massively scalable. The out-of-the-box configuration can be less than optimal if the workload is non-persistent (that is, HTTP 1.0 without the KeepAlive header), or for a lightly loaded system that is primarily servicing keep-alive connections.

Keep-Alive Count

This section in perfdump has two numbers:

The maximum number of connections allowed in keep-alive mode can be configured using the MaxKeepAliveConnections magnus.conf directive.

Note –

The number of connections specified by the maximum connections setting is divided equally among the keep-alive threads. If the maximum connections setting is not equally divisible by the keep-alive threads setting, the server might allow slightly more than the maximum number of simultaneous keep-alive connections.

Keep-Alive Hits

The keep-alive hits, or the number of connections processed, is the number of times a request was successfully received from a connection that was kept alive.

This setting is not tunable.

Keep-Alive Flushes

The number of times the server had to close a connection because the total number of connections added exceeded the keep-alive maximum connections setting. The server does not close existing connections when the keep-alive count exceeds the maximum connection size. Instead, new keep-alive connections are refused and the number of connections refused count is incremented.

Keep-Alive Refusals

The number of times the server could not complete the connection to a keep-alive thread, possibly due to too many persistent connections (or when total number of connections added exceeds the keep-alive maximum connections setting). The suggested tuning is to increase the keep-alive maximum connections.

Keep-Alive Timeouts

The number of times the server closed idle keep-alive connections because client connections timed out without any activity. This statistic is useful to monitor. There is no specific tuning advised for this setting.

Keep-Alive Timeout

The time, measured in seconds, before idle keep-alive connections are closed.

Keep-Alive Poll Interval

The keep-alive poll interval specifies the interval in seconds at which the system polls keep-alive connections for further requests. The default is 0.001 second, the lowest value allowed. It is set to a low value to enhance performance at the cost of CPU usage.

Keep-Alive Threads

The KeepAliveThreads magnus.conf directive can be used to specify the number of keep-alive threads.

Tuning for HTTP 1.0-Style Workload

Since HTTP 1.0 results in a large number of new incoming connections, the default acceptor threads of 1 per listen socket would be suboptimal. Increasing this to a higher number should improve performance for HTTP 1.0-style workloads. For instance, for a system with 2 CPUs, you might want to set it to 2. You might also want to reduce the keep-alive connections, for example, to 0.

HTTP 1.0-style workloads can have many connections established and terminated.

If users are experiencing connection timeouts from a browser to Proxy Server when the server is heavily loaded, you can increase the size of the HTTP listener backlog queue by setting the HTTP listener's listen queue size to a larger value, such as 8192. The listen queue size can be specified using the "Configure System Preferences" screen in the admin interface.

The HTTP listener listen queue specifies the maximum number of pending connections on a listen socket. Connections that time out on a listen socket whose backlog queue is full fail.

Tuning for HTTP 1.1-Style Workload

While tuning server-persistent connection handling, balancing throughput and latency is a challenge. The keep-alive poll interval and timeout control latency. Lowering the value of these settings is intended to lower latency on lightly loaded systems, for example, to reduce page load times. Increasing the values of these settings is intended to raise aggregate throughput on heavily loaded systems, for example, by increasing the number of requests per second the server can handle. However, if there is too much latency and too few clients, aggregate throughput suffers as the server sits idle unnecessarily. As a result, the general keep-alive subsystem tuning rules at a particular load are as follows:

Also, chunked encoding could affect the performance for HTTP 1.1 workload. Tuning the response buffer size can positively affect the performance. A higher response buffer size, set using the magnus.conf parameter, ChunkedRequestBufferSize would result in sending a Content-length: header, instead of chunking the response.

You can also set the buffer size for a Service-class function in the obj.conf file, using the UseOutputStreamSize parameter. UseOutputStreamSize overrides the value set using the output-buffer-size property. If UseOutputStreamSize is not set, Proxy Server uses the output-buffer-size setting. If the output-buffer-size is not set, Web Server uses the output-buffer-size default value of 8192.

The following example shows setting the buffer size for the nsapi_test Service function:

<Object name="nsapitest">
 ObjectType fn="force-type" type="magnus-internal/nsapitest"
 Service method=(GET) type="magnus-internal/nsapitest" fn="nsapi_test"