Apache keepalive Setup and optimization-old yellow Note box

Original paste: http://cache.baidu.com/c?m= 9d78d513d99003fc09b7c3690d678e314e16d33d679387013894cd47c9221d03506790a63a675541c4c50b3852f31c0cb9b0217240527de8869ed51b9 ae4c57469952d677a1e8c4319851afcc8417491709558eaac4ae1bbfb62c3a58184dc5600cb&p=867dca15d9c246be00be9b781654 &user=baidu

ApacheOf KeepAliveSetup and optimization-old yellow Note box Tom Zheng | 2008-6-1 18:10:56

A few days ago a friend of the system on a little problem, gave him some optimization strategy, turned around, he heard that turn off Apache KeepAlive can improve performance, especially to help him say. I'll just take a note here and spare it later.

Let's talk about Apache 's KeepAlive settings.

KeepAlive in the Apache Core Setup Description:
Keep-alive extends the persistent link characteristics from http/1.0 and http/1.1. Provides a long-lasting HTTP session for multiple requests in the same TCP connection. In some cases, this will accelerate the delay to 50% of HTML documents that contain a large number of images. After the Apache1.2 version, you can set KeepAlive on to enable persistent links.
For http/1.0 clients, a persistent link connection is used only when the client specifies to use it. In addition, persistent link connections are established with http/1.0 clients only if the length of the transmitted content is known in advance. This means that content that is variable in length, such as CGI output, SSI pages, and server-generated directory listings, will generally not be able to use persistent link connections with http/1.0 clients. For http/1.1 clients, if no special designation is made, persistence will be the default connection method. If the client makes a request, the block encoding is used to resolve the problem of sending unknown length content in the persistent link.

Another related is KeepAliveTimeout's setup instructions in the Apache Core:
The number of seconds that Apache waits for the next request before closing a persistent connection. Once a request is received, the timeout value is set to the number of seconds specified by the timeout directive.
For a high load server, a large keepalivetimeout value can cause some performance problems: the larger the timeout value, the more processes that remain connected to the idle client.

Finally, there is a note about maxkeepaliverequests in the core:
The maxkeepaliverequests directive restricts the number of requests allowed per connection when KeepAlive is enabled. Setting this value to "0" will not limit the number of requests. We recommend that you set this value to a relatively large value to ensure optimal server performance.

We can already understand the principle of KeepAlive by stating the Apache settings. In the case of a Web page that contains many pictures, the client will issue multiple HTTP requests in an instant, and a TCP connection can be made multiple times to greatly reduce the response speed. By continuing the connection, you can allow users to emit multiple HTTP requests in a single TCP connection, reducing the number of TCP connections established and increasing the response speed. By Access_log, we can count the number of consecutive HTTP requests, the time interval, and the amount of traffic to determine the values of maxkeepaliverequests and KeepAliveTimeout. KeepAliveTimeout too small to play the role of continuous connection; it's too big, persistent connections, wasting TCP connections, and worse, the number of httpd processes in the system is increasing, resulting in increased system load and even a loss of response from the server.

However, when your server is only processing Dynamic Web requests, because the user rarely instant request multiple dynamic pages (usually open the page after a few minutes to read the next page), at this time open KeepAlive is tantamount to a waste of TCP connections.

What, what determines if we're going to open the KeepAlive factor is very simple to determine, that is, whether a user in a page request will send multiple HTTP requests to the server.

For one of my friends, their server has a dynamic application, with all the pictures, I looked at, estimating their home page issued in the following types of requests: text/html, Text/css, Application/octet-stream, text/ JavaScript, Image/gif, Image/jpeg. A first page issued 181 requests (I read all the requests, note that all requests are the same domain name). This may be generated by the application only text/html and Application/octet-stream, text/html only once in this request, and Application/octet-stream only 4 times. Is it helpful for them to close the KeepAlive ? My reply is not helpful, and will make the server's service quality worse.

If this is the case, what to do. My suggestion is as follows:
1. If we have only one request per page that is dynamically generated, and 180 (there may be 4 not, but not important) are static, which should be static and dynamic separation to two servers (a machine can be). Closes the dynamically applied keeplive and opens the keeplive of the static server.
2. Deploy a four-tier switch or a seven-tier swap or cache server before the front end, which will allow the system to be expanded and, at the same time, better for the server's keeplive to open.
3. You should consider optimizing their Apache , heard that a process has up to XXM memory footprint, relatively scary, within 10M more normal said, but this is an option.

Http://blog.opensource.org.cn/hdcola/2008/05/apachekeepalive-1.html#more