|
The only thing keepalive does is not run the 4-way close handshake on the TCP connection directly after fulfilling a request. It instead waits for a passive close, OR in the case of a timeout it does an active close.
There are benifits to this. For one, since the client would then be sending the 4-way handshake (FIN/ACK/FIN/ACK), the server would be doing a passive close on the TCP connection so the kernel would not put that child processess into TIME_WAIT. Additionally since most browsers use non-blocking sockets and async recvs, you can ususally get a few requests for each child fork().
However DO NOT set the Keepalive timeout too high! You do NOT need the default value of 15 seconds. Since Apache uses a pre-forking model to handle calls to accept, it is faster to just hand the request to a new child process if more than 2-3 seconds elapse in between requests. Just make sure that your MinServers and SpareServers are set to resonable values so that you don't run into a ramp-up effect of processess trying to fork().
The less time that Apache spends in the select() accept() loop the better because Apache uses a Mutex to protect the serialization of sockets which ends up blocking, so since most clients support HTTP/1.1 and Keepalive, it is usually a slight speed increase beacuse it does not get stuck polling the mutex. If for some reason the client only supports HTTP/1.0 (its usually a bot at this point), the Keepalive will timeout and apache will make an active close on the connection. so you only lost the initial timeout value over not using keepalive at all.
|