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:
KeepAliveInfo: -------------------- KeepAliveCount 0/256 KeepAliveHits 0 KeepAliveFlushes 0 KeepAliveRefusals 0 KeepAliveTimeouts 0 KeepAliveTimeout 30 seconds
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:
Dynamic content, such as a CGI, does not have an HTTP content-length header set. This applies only to HTTP/1.0 requests. If the request is HTTP/1.1, the server honors keep-alive requests even if the content-length is not set. The server can use chunked encoding for these requests if the client can handle them (indicated by the request header transfer-encoding: chunked). For more information about chunked encoding, see the Sun Java System Web Server 6.1 SP9 NSAPI Programmer’s Guide.
Request is not HTTP GET or HEAD.
The request was determined to be bad. For example, if the client sends only headers with no content.
You can configure the number of threads used in the keep-alive system by:
Setting or changing the KeepAliveThreads value in the Magnus Editor of the Server Manager
This setting has two numbers:
Number of connections in keep-alive mode
Maximum number of connections allowed in keep-alive mode simultaneously
You can tune the maximum number of sessions that the server allows to wait at one time before closing the oldest connection by:
Setting or changing the MaxKeepAliveConnections value in the Magnus Editor of the Server Manager
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.