KeepAliveTimeout parameter in IBM HTTP Server

Posted on by

As you might have read in my article about Cognos, I had to increase the value of the KeepAliveTimeout parameter in the httpd.conf of the IBM HTTP Server to be able to build the Transformer Powercubes. As the Connections tuning guide advices to set this parameter to 5 seconds and I had to increase it to 30, I was wondering what this increase could do to my environment. I asked IBM and they gave this answer:

“This value is less than the ThinkTime defined in IBM®’s scripts to ensure that testing is conservative. Each user is assumed to open a new TCP connection for each page view. However, in a live environment, it can be helpful to increase the KeepAliveTimeout. A higher timeout value can increase contention for HTTP server processes. If you are running out of HTTP processes, decrease this value.”

—

This value is based on an average ThinkTime of 7sec that we use in our tests. ThinkTime is the time where a user pauses, stop and does nothing (reading, talking, etc ) before navigating to a different page. While the user is doing nothing, it is preferable to release the connection for other clients.

 

The rational behind setting the KeepAliveTimeout to 5 is to close idle connections. The default value of 10 in our test scenario will hold a connection unnecessarily keeping other processes in a waiting state.

 

So setting the KeepAliveTimeout to a higher value might cause performance issues in a busy loaded environment as more server processes will be kept waiting on connections with idle clients.

 

Setting it to a too small value will also cause some performance overheads of recreating and closing TCP connections for future similar client requests.

—

 

In other words – 5 is usually a good start, but then you might adapt it based on your environment, needs, workload, etc. There are monitoring tools in place which can give you info what is happening to your system.

So my guess that I might need more HTTP servers because of increasing this setting was correct. In this environment extra webservers are automatically spinning up if the number of idle threads becomes low and I do see an extra webserver spin up more often than before increasing this parameter. It’s not dramatic though. I estimate we need about 10% more threads.