HTTP 1.0 KeepAlive

Purpose

One of the features of HTTP is its statelessness. Practice has shown, however, that a separate connection for every request invokes a great deal of overhead, as well as abnormally high server loads. This is particularly true for slow connections or connections that must go through many routers.

In response to this, NCSA HTTPd now allows for multiple requests to be handled over a single connection with browsers which support this feature. Using one such browser, NCSA Mosaic for Windows, we found a speed increase of up to 30% using this feature. Of course, the actual performance improvement in practice will depend on the particular connection.

Syntax

Three new directives have been introduced to configure the keepalive feature.

KeepAlive on | off

Where the syntax "on | off" means that either "on" or "off" may be present. This directive allows the administrator to enable or disable keepalive.

KeepAliveTimeout N

Where N is the number of seconds to maintain the connection between requests. If N seconds passes since the last client request on the connection, the server will close the connection.

MaxKeepAliveRequests N

Where N is an integer indicating the maximum number of requests that the server will accept during a keepalive session. After the client has issued this many requests, the server closes the connection.

File

httpd.conf

Defaults

If you do not include the KeepAlive directive in httpd.conf, keepalive will not be enabled.

The default for KeepAliveTimeout is 10 seconds. However, experience and experimentation will probably be required to determine a "good" value.

The default for MaxKeepAliveRequests is 5. However, if you do not want a limit imposed, you can use a maximum value of 0, which will then allow any number of requests during a keepalive session. For example:

MaxKeepAliveRequests 0

Points to Consider

Since HTTPd is a pre-forking server, most requests under normal load are handled by persistent processes. If these processes are busy handling keepalive sessions, then additional processes may be initiated to deal with requests. If the number of processes reaches Maxservers, then future requests will be handled by forked, non-persistent processes. Thus, there is a chance that many long keepalive sessions will lead to a large number of processes. We are still studying the effect of keepalive on the overall behavior of HTTPd.

Shortly after implementing the keepalive feature in HTTPd, a similar mechanism known as session extension, was proposed by the IETF for HTTP1.1. The mechanics are similar to our current implementation, but there are differences. We will most likely be modifying our keepalive implementation to be compatible with the session extension proposal during this beta. This should, for the most part, be transparent to the administration of HTTPd.

For Developers: