Keepalive for Apache Optimization

Before talking about Apache keepalive, we need to have a simple understanding of the Web data loading process.
Here we will first introduce a test website loading tool: pingdom tools. In this tool, we enter a URL to test the loading speed. The most important thing is to observe the loading process:

The meaning of each block is: yellow indicates the HTTP start time, Green indicates the HTTP request link time, and blue indicates the loading time;
From the result graph, we can see that:
1) All requests here refer to HTTP requests, which are divided into three steps. The first step is to start, the second step is to link, and the third step is to officially download
2) For all webpages, start the HTTP request and link request of the homepage and download the data at the top of the homepage. Only one HTTP request can be used to download the data.
3) when some data on the home page is downloaded, the css js file will be downloaded (Note: This tool does not count JS). In future data downloads, 10 HTTP requests are concurrently downloaded.
4) When downloading the current 10 HTTP request data, other resources need to wait. Therefore, we should pay attention to the number of web resources during the optimization process.
5) When downloading a web resource, if the resource is relatively large, it will take a long time to load it, so pay attention to the size. In the above test, there is another part in the process of requesting to download resources: TCP request connection and disconnection, and this article officially said this request. So what is the relationship between HTTP requests and TCP requests? Simply put, a TCP request is closer to the underlying layer and is an application request such as HTTP on it. Therefore, we can consider that a TCP request includes many HTTP requests, can be set in Apache). At the same time, TCP connections and disconnections consume more memory resources and time than HTTP requests. Let's talk about the keepalive settings of Apache. Keepalive in Apache
Core settings:
Keep-alive extends the persistent link features of 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 thing that is related to keepalivetimeout in Apache
Core settings:
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, there is a description of maxkeepaliverequests in core:
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 values 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. How can I 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.
How to verify whether Apache on your server has enabled this function (if you buy a virtual space, the network management usually does not enable it for you because it consumes too much memory )? Webmasters station tool query, and gzip compression together to query.
Conclusion: persistent connections have both advantages and disadvantages. On the one hand, persistent connections consume too much memory. On the other hand, Apache persistent connections have different effects on Dynamic and Static requests, for dynamic requests, a single request occupies a TCP segment. For static content, it is advantageous to download multiple HTTP requests at the same time. Therefore, we assume that the Web is divided into servers, one server stores static html css js, especially images. One server stores dynamic page requests. Theoretically, the results will be better, but I have not tested the actual results and test data.