Configuring Keep-Alive connection in Apache Http Server

When i tried accessing a page Login page of WebSPhere Portal server on my local i noticed that Keep-Alive was not set and the browser took 4.05 seconds with empty cache



In most of installations you will have a Http Server in front of your application server, and you can configure Apache Http server to use keep alive persistent connection by changing following configuration in httpd.conf


#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 100


The httpd.conf has 3 settings to control tune keep-alive connection

  1. KeepAlive: Value of this flag indicates if you want to use persistent Keep-Alive connection or not. Setting it true will turn the Keep-Alive connection on

  2. MaxKeepAliveRequests Value of this property indicates what should be value of max attribute, value of 100 means the Keep-Alive: max=100 header would be sent to the browser, to indicate that the server is going to keep this connection open for next 100 requests

  3. KeepAliveTimeout : Value of this property indicates what should be value of timeout attribute in Keep-Alive header. Value of 300 means it will set Keep-Alive: max=300, this will let browser know that the persistent connection will timeout in 300 seconds



After i made these configuration changes and restarted my Apache Http Server, when i made the same login request again i could see that Apache was setting following headers


I wanted to see overall impact of Keep-Alive so after making the changes i cleaned up my cache and performed the same login page request as before now the response time came down to 2.95s from 4.2 seconds below.



Both my browser and server are on the same machine, so the performance improvement could be bigger when the client is accessing remote server

1 comment:

Anonymous said...

Thanks, this was just what I needed