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

How HTTP persistent connection between browser and server work ?

The Keep-alive is deprecated in Http 1.1 specification, but it is still commonly used by browsers and servers. Clients implementing HTTP/1.0 keep-alive connection can request that a connection be kept open by including the Connection: Keep-Alive request header. If the server is willing to keep the connection open for the next request, it will respond with the same header in the response. If there is no Connection: Keep-Alive header in the response, the client assumes that the server does not support keep-alive and that the server will close the connection when the response message is sent back.

Keep-Alive header must be sent with all messages that want to continue the persistent If the client does not send a Connection: Keep-Alive header the server will close the connection after that request. Same thing if the response does not have Connection: Keep-Alive header browser will assume that server has closed the connection.

The browsers make use of connection close signal even to figure out end of message body. So if you want the connection to remain open, you will have to set correct value for Content-Length, also set correct Content Type header set or the message should be encoded with the chuncked transfer encoding.

The keep-alive behavior can be tuned by following comma-separated options specified in the Keep-Alive general header

1. The timeout parameter is sent in a Keep-Alive response header. It estimates how long the server is likely to keep the connection alive for.


2. The max parameter is sent in a Keep-Alive response header. It estimates how many more HTTP transactions the server is likely to keep the connection alive for.


3. The Keep-Alive header also supports arbitrary unprocessed attributes, primarily for diagnostic and debugging purpose.
   

The Keep-Alive header is completely option but is permitted only when Connection:Keep-Alive header is present.

Connection: Keep-Alive
Keep-Alive: max=100, timeout=300

These headers in response, will tell browser that server will keep this connection open for next 100 resource request and if you don't make request it will timeout in 300 seconds

What is Http Persistent connection

HTTP protocol has a concept of persistent connection, which means the connection is not closed after Http request and response transaction, instead the Http connection is kept open across multiple transaction. I.e. browser opens a Http connection to get a web page and then reuses that connection to get images, JavaScript, CSS on the page. By reusing an idle, persistent connection that is already open to a target server, you can avoid the slow connection establishment as well as slow start-up throttle.

Persistent connections provide quite few advantages like reduce the delays and overheads of connection establishment, keep the connections in a tuned state, and reduce the potential number of open connections. But if you don't handle persistent connections with care, you may end up accumulating a large number of idle connections, consuming local resources and resources on remote clients and servers.

There are two types of persistent connections

1. Http/1.0: had concept of keep-alive connections:


2. Http/1.1 has concept of persistent connections.

How HTTP connection works ?

When you try to access particular URL in your browser it goes through following steps to get response

• First browser needs to determine the IP address and port number of the web server from the URL. If the host name in the URI was not recently visited it may take tens of seconds to convert the host name from a URI into an IP address using the DNS resolution infrastructure


• Next the client sends a TCP connection request to the server and waits for the sever to send back a connection acceptance reply. Connection setup delay occurs for every new TCP connection. This usually takes a second or two but it can add up quickly when hundreds of Http transactions are made.


• Once the connection is established, the client sends the HTTP request over the newly established TCP pipe. The web server reads the request message from the TCP connection as the data arrives and processes the request. It takes time for request message to travel over the internet and get processed by the server


• The web server then writes back the Http response, which takes some time

YOu can use Firebug to loot at the time spent by browser in each of these steps, take a look at following screen shot



Firebug will display timeline for each of the resource, different colors in the timeline display time spent in each of the phase of getting response, when you take your mouse over particular resource it will display a popup with details on time spent in each phase

• DNS Lookup This is amount of time it took for Firefox to figure out IP address and port number from the URL. Please note that Firefox will cache the results of DNS lookups. This time is longer for first request to host name


• Connecting This is amount of time it took for Firefox to establish Http connection with the server


• Sending This is amount of time it takes for Firefox to send the request


• Waiting Time taken for server to read the request process it and start sending message


• Receiving Time taken for firefox to receive the response sent by server

What is TCP startup throttle

TCP slow start throttles the number of packets a TCP endpoint can have in flight at any one time. Put simply, each time a packet received successfully, the sender gets permission to send two more packets. If an Http transaction has a large amount of data to send, it cannot send all the packages at once. It must send one packet and wait for an acknowledgement; then it can send two packets, each of which must be acknowledged, which allows four packets, etc. Because of this congestion-control feature, new connections are slower than tuned connections that are already have exchanged, a modest amount of data. Because tuned connections are faster, HTTP includes facilities that let you reuse existing connection.