Sun Java System Web Server 6.1 SP6 Performance Tuning, Sizing, and Scaling Guide

Keep-Alive/Persistent Connection Information

This section provides information about the server’s HTTP-level keep-alive system. For additional tuning information, see Monitoring Current Activity Using the perfdump Utility

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

KeepAliveCount        0/256
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     0
KeepAliveTimeout      30 seconds

Note –

The name "keep-alive" should not be confused with TCP "keep-alives." Also, note that the name "keep-alive" was changed to "Persistent Connections" in HTTP/1.1, but the .perf continues to refer to them as "KeepAlive" connections.

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

To deal with this problem, the server maintains a "Maximum number of waiting keep-alive connections" counter. 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 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:


You can configure the number of threads used in the keep-alive system by:


This setting has two numbers:


You can tune the maximum number of sessions that the server allows to wait at one time before closing the oldest connection by:

Note –

The number of connections specified by MaxKeepAliveConnections is divided equally among the keep-alive threads. If MaxKeeepAliveConnections is not equally divisible by KeepAliveThreads, the server may allow slightly more than MaxKeepAliveConnections simultaneous keep-alive connections.


The number of times a request was successfully received from a connection that had been kept alive.

This setting is not tunable.


The number of times the server had to close a connection because the KeepAliveCount exceeded the MaxKeepAliveConnections. In the current version of the server, the server does not close existing connections when the KeepAliveCount exceeds the MaxKeepAliveConnections. Instead, new keep-alive connections are refused and the KeepAliveResusals count is incremented.


The number of times the server could not hand off the connection to a keep-alive thread, possibly due to too many persistent connections (or when KeepAliveCount exceeds MaxKeepAliveConnections). Suggested tuning would be to increase MaxKeepAliveConnections.


The time (in seconds) before idle keep-alive connections are closed.


The number of times the server terminated keep-alive connections as the client connections timed out, without any activity. This is a useful statistic to monitor; no specific tuning is advised.


This option is not displayed in perfdump or Server Manager statistics. However, for UNIX/Linux users, it should be enabled for maximum performance.

ProcedureTo enable native poll for your keep-alive system from the Server Manager

  1. Go to the Server Manager Preferences tab and select the Mangus Editor.

  2. From the drop-down list, choose Keep-Alive Settings and click Manage.

  3. Use the drop-down list to set UseNativePoll to On.

  4. Click OK, and then click Apply.

  5. Select Apply Changes to restart the server for your changes to take effect.