Enable and disable keepalive settings

In the Apache server, keepalive is a Boolean value. On indicates opening, and off indicates disabling. This command exists in many other HTTPd servers.

The keepalive configuration command determines whether to immediately close the TCP connection after processing the HTTP request initiated by the user. If keepalive is set to on, the user will not immediately disconnect after one access, if there is still a request, it will continue to be completed in this TCP connection, instead of repeatedly establishing a new TCP connection and closing the TCP connection, which can improve the user access speed.

We will consider three situations:
1. When a user browses a webpage, in addition to the webpage itself, it also references multiple JavaScript files, multiple CSS files, and multiple image files, all of which are on the same HTTP server.
2. When a user browses a webpage, in addition to the webpage itself, a Javascript file and an image file are also referenced.
3. A user browses a dynamic web page, which is instantly generated by the program and does not reference other content.

In the above 3 cases, I think: 1 is the best choice to enable keepalive, 2 is random, and 3 is the best choice to disable keepalive.

Let me analyze the cause. In Apache, what are the differences between enabling and disabling the keepalive function on the server? Let's take a look at the theoretical analysis.

After keepalive is enabled, it means that every time a user completes all access, the TCP connection will be closed after a certain period of time. Before closing the connection, there must be an Apache process corresponding to this user and cannot process other users. Assume that the keepalive timeout time is 10 seconds, and the server processes Access from 50 independent users per second, in the system, the total number of Apache processes is 10*50 = 500. If a process occupies 4 MB of memory, a total of 2 GB of memory is consumed. Therefore, in this configuration, memory consumption, but the advantage is that the system only processes 50 TCP handshakes and closes the operation.

If keepalive is disabled and 50 users are allowed to access each second, if the number of consecutive requests is 3, the total number of Apache processes is 50*3 = 150, if each process still occupies 4 MB of memory, the total memory consumption is 600 mb. This configuration can save a lot of memory. However, the system processes 150 TCP handshakes and closes, therefore, it will consume more CPU resources.

Let's take a look at the practice.

In a group of servers that process a large number of dynamic web pages, I started the keepalive function and often observed that there were a large number of Apache processes when the user access volume was large, and the system frequently used swap memory, the system is unstable and sometimes the load fluctuates greatly. After the keepalive function is disabled, it is obvious that the number of Apache processes is reduced, the idle memory is increased, the memory used for file system cache is also increased, and the CPU overhead is increased, however, the service is more stable, and the system load is also relatively stable. There is little fluctuation in the load range, and the load is reduced to a certain extent. What is not obvious is: when the traffic volume is small, the average system load has not changed significantly.

To sum up, whether or not the keepalive function is disabled on servers with ample memory, the server performance will not change significantly. If the server memory is small, or when the server has a very large number of file system accesses, or mainly handles Dynamic Web Services, disabling keepalive can save a lot of memory, and the saved memory is used for the file system cache, it can improve the performance of File System Access and make the system more stable.

　　Supplement 1:
I think the keepalive option should be disabled based on the following formula.

Under ideal network connection conditions, the number of Apache processes and memory usage in the system can be expressed using the following formula:
Httpdprocessnumber = keepalivetimeout * totalrequestpersecond/average (keepaliverequests)
Httpdusedmemory = httpdprocessnumber * memoryperhttpdprocess

Change to Chinese:
Total Apache processes = keepalivetimeout * Number of HTTP requests per second/average keepalive requests
Apache memory usage = total Apache processes * Average memory usage per Process

Note:
[Average keepalive requests] indicates the number of HTTP requests that are continuously sent after each user connects to the server. When keepalivetimeout and other 0 or keepalive are disabled, keepalivetimeout is not involved in multiplication. From the preceding formula, if there are more [user requests per second], the value of [keepalivetimeout] is large, if the value of the [average keepalive request] is small, there will be more [Apache processes] and [Memory]. However, when the value of the [average keepalive request] is larger, [Apache process count] and [Memory] tend to decrease.

Based on the above formula, we can calculate that when the average keepalive request is <= keepalivetimeout, it is cost-effective to disable the keepalive option. Otherwise, we can consider opening it.

Supplement 2:Keepalive this parameter controls whether Apache allows multiple requests in a connection. It is enabled by default. However, for most Forum sites, it is usually set to off to disable this support.

Supplement 3:If the application squid service or other layer-7 devices are running in front of the server, keepalive on is set to enable persistent connections.

Keepalive is critical when the front-end has squid. Remember on

Description of keepalive settings in Apache core: keep-alive extends the persistent link feature from HTTP/1.0 and HTTP/1.1. Provides a long-term http session for multiple requests in the same TCP connection. In some cases, this method may accelerate the latency of HTML documents containing a large number of images by 50%. After apache1.2, you can set keepalive on to enable persistent connections.

For HTTP/1.0 clients, persistent connection is used only when the client is specified. In addition, a persistent connection is established with the HTTP/1.0 client only when the length of the transmitted content is known in advance. This means that the undefined content, such as CGI output, SSI page, and directory list generated by the server will not be able to use a persistent connection established with the HTTP/1.0 client. For HTTP/1.1 clients, if no special settings are made, the persistent connection is the default connection method. If the client initiates a request, it will use block encoding to solve the problem of sending unknown length content in a persistent link.

Another issue is how to set keepalivetimeout in Apache core: the number of seconds that Apache waits for the next request before closing the persistent connection. Once a request is received, the timeout value is set to the number of seconds specified by the timeout command. For high-load servers, the keepalivetimeout value is more likely to cause some performance problems: the larger the timeout value, the more processes that are connected to the idle client.

Finally, the description of maxkeepaliverequests in core is as follows:The maxkeepaliverequests command limits the number of requests allowed by each connection when keepalive is enabled.If you set this value to "0", the number of requests is not limited. We recommend that you set this value to a relatively large value to ensure optimal server performance.

Through Apache settings, we can understand the principles of keepalive. For a Web page containing many images, the client sends multiple HTTP requests instantly. At this time, setting up multiple TCP connections greatly reduces the response speed. At this time, through continuous connection, users can send multiple HTTP requests in a TCP connection, reducing the number of established TCP connections and improving the response speed. We can use access_log to calculate the number of consecutive HTTP requests, the interval, and the number of visits to determine the value of maxkeepaliverequests and keepalivetimeout. Keepalivetimeout is too small to play the role of continuous connections; it is too large, continuous connection is delayed, a waste of TCP connections not to mention, and worse, the number of httpd processes in the system will continue to increase, this increases the system load and even causes the server to lose response.

However, when your server is only Processing dynamic web page requests, because users rarely instantly request multiple dynamic web pages (usually the next page is clicked after the page is opened for a long time ), opening keepalive is a waste of TCP connections.

What determines whether or not we want to enable keepalive is simply determined, that is, whether the user sends multiple HTTP requests to the server in a page request.

For my friends who have dynamic applications on their servers and all the images, I looked at them and estimated that the types of requests sent on their homepage are as follows: text/html, text/CSS, application/octet-stream, text/JavaScript, image/GIF, and image/JPEG. A home page sends 181 requests (I read all requests and note that all requests are the same domain name ). Here, only text/html and application/octet-stream may be generated by the application. In this case, text/html is generated only once, and application/octet-stream is generated only four times. Is it helpful for them to disable keepalive? My reply is not helpful, and it will make the server's service quality worse!

What if this is the case? My suggestions are as follows:
1. if only one request on each page is dynamically generated, and 180 (four of them may not be, but not important) are static, which of the following methods should be used to separate static and dynamic data on two servers ). Disable the dynamic application keeplive and open the static server keeplive.
2. layer-4 switching or layer-7 switching or cache servers are deployed before the front-end. This will enable system expansion and enable the server's keeplive to be opened with better results.
3. We should consider optimizing their Apache. I heard that a process occupies up to xxm of memory, which is terrible. It is normal to say within 10 m, but this is an option.

After reading this article, we can understand why the company image server needs to be separated from other servers.

But I don't know if the image service should be provided separately from other services for the request-based sip?

Http://blog.cnr.cn/18/viewspace-11652.html

Take a look at the following:

Http://doc.linuxpk.com/3191.html apache2.0 Performance Optimization