(轉)apache的keepalive和keepalivetimeout（apache優化）

KeepAlive指的是保持鏈接活躍，相似於Mysql的永久鏈接。

 

若是將KeepAlive設置爲On，那麼來自同一客戶端的請求就不須要再一次鏈接，避免每次請求都要新建一個鏈接而加劇服務器的負擔。    

KeepAlive的鏈接活躍時間固然是受KeepAliveTimeOut限制的。若是第二次請求和第一次請求之間超過KeepAliveTimeOut的時間的話，第一次鏈接就會中斷，再新建第二個鏈接。

 

若是KeepAliveTimeOut設置的時間太短，例如設置爲1秒，那麼APACHE就會頻繁的創建新鏈接，固然會耗費很多的資源；反過來，若是KeepAliveTimeOut設置的時間過長，例如設置爲300秒，那麼APACHE中確定有不少無用的鏈接會佔用服務器的資源，也不是一件好事。 

 

因此，到底要把KeepAliveTimeOut設置爲多少，要看網站的流量、服務器的配置而定。

其實，這和MySql的機制有點類似，KeepAlive至關於mysql_connect或mysql_pconnect，KeepAliveTimeOut至關於wait_timeout。  

 

那麼咱們考慮3種狀況：

1。用戶瀏覽一個網頁時，除了網頁自己外，還引用了多個 javascript 文件，多個css 文件,多個圖片文件，而且這些文件都在同一個 HTTP 服務器上。

2。用戶瀏覽一個網頁時，除了網頁自己外，還引用一個 javascript 文件，一個圖片文件。

3。用戶瀏覽的是一個動態網頁，由程序即時生成內容，而且不引用其餘內容。

我認爲：1 最適合打開 KeepAlive ，2 隨意，3 最適合關閉 KeepAlive

 

在 Apache 中，打開和關閉 KeepAlive 功能，服務器端會有什麼異同呢？

理論分析:

打開 KeepAlive 後，意味着每次用戶完成所有訪問後，都要保持必定時間後才關閉會關閉TCP鏈接，那麼在關閉鏈接以前，必然會有一個apache進程對應於該用戶而不能處理其餘用戶，假設KeepAliveTimeOut=10s,服務器每秒處理50個獨立用戶訪問，那麼系統中Apache的總進程數就是10×50=500個，若是每一個進程佔用4M，那麼總消耗2G內存，這種配置至關消耗內存，但好處是隻處理了50次TCP握手和關閉操做。

 

若是關閉 KeepAlive，若是仍是每秒50個用戶訪問，若是用戶每次連續的請求數爲3個，那麼apache的總進程數就是50×3=150，每一個進程佔用4M那麼總消耗爲600M，這種配置節省大量內存，可是系統會處理150個TCP握手和關閉操做，所以會多消耗CPU資源。

 

總結：

在內存很是充足的服務器上，不論是否關閉 KeepAlive 功能，服務器性能不會有明顯變化；

若是服務器內存較少，或者服務器有很是大量的文件系統訪問時，或者主要處理動態網頁服務，關閉KeepAlive後能夠節省不少內存，而節省出來的內存用於文件系統Cache，能夠提升文件系統訪問的性能，而且系統會更加穩定。

 

補充1：

是否應該關閉KeepAlive選項,判斷公式

在理想的網絡鏈接情況下，系統的 Apache 進程數和內存使用能夠用以下公式表達：

HttpdProcessNumber = KeepAliveTimeout*TotalRequestPerSecond/Average(KeepAliveRequests)

HttpdUsedMemory = HttpdProcessNumber*MemoryPerHttpdProcess

換成中文：

總Apache進程數 = KeepAliveTimeout * 每秒種HTTP請求數 / 平均KeepAlive請求

Apache佔用內存 = 總Apache進程數 * 平均每進程佔用內存數

 

[平均KeepAlive請求]數，是指每一個用戶鏈接上服務器後，持續發出的 HTTP請求數。當KeepAliveTimeout 等0或者KeepAlive關閉時，KeepAliveTimeout不參與乘的運算從上面的公式看，若是[每秒用戶請求]多，[KeepAliveTimeout] 的值大，[平均KeepAlive請求] 的值小，都會形成 [Apache進程數]多和[內存]多，可是當 [平均KeepAlive請求] 的值越大時，[Apache進程數] 和 [內存] 都是趨向於減小的。

基於上面的公式，咱們就能夠推算出當平均KeepAlive請求 <= KeepAliveTimeout 時，關閉 KeepAlive 選項是划算的，不然就能夠考慮打開。

 

補充2：

KeepAlive該參數控制Apache是否容許在一個鏈接中有多個請求，默認打開。但對於大多數論壇類型站點來講，一般設置爲off以關閉該支持。

 

補充3：

若是服務器前跑有應用squid服務，或者其它七層設備,KeepAlive On設定要開啓持續長鏈接.

 

KeepAlive在Apache Core中的設置說明： 

1.對於HTTP/1.0的客戶端來講，僅當客戶端指定使用的時候纔會使用持久連接鏈接。此外，僅當可以預先知道傳輸的內容長度時，纔會與HTTP/1.0的客戶端創建持久連接鏈接。這意味着那些長度不定的內容，諸如CGI輸出、SSI頁面、以及服務器端生成的目錄列表等內容通常來講將沒法使用與HTTP/1.0客戶端創建的持久連接鏈接。對於HTTP/1.1的客戶端來講，若是沒有進行特殊指定，持久將是默認的鏈接方式。若是客戶端進行了請求，將使用分塊編碼以解決在持久連接裏發送未知長度內容的問題。

2.對於高負荷服務器來講，KeepAliveTimeout值較大會致使一些性能方面的問題：超時值越大，與空閒客戶端保持鏈接的進程就越多。

3.MaxKeepAliveRequests指令限制了當啓用KeepAlive時，每一個鏈接容許的請求數量。若是將此值設爲"0"，將不限制請求的數目。咱們建議最好將此值設爲一個比較大的值，以確保最優的服務器性能。

 

在對於一個包含許多圖片的網頁來講， 客戶端會在瞬間發出多個HTTP請求，此時屢次創建TCP鏈接會大大下降響應速度。此時經過持續鏈接，能夠容許用戶在一個TCP鏈接中發出多個HTTP請求，減小TCP鏈接創建次數，提升響應速度。咱們能夠經過access_log統計出連續HTTP請求出現的次數、間隔時間、訪問量，以肯定MaxKeepAliveRequests 和KeepAliveTimeout的值。KeepAliveTimeout過小發揮不了持續鏈接的做用；太大了，持續鏈接遲遲不斷，浪費TCP鏈接數不說，更糟糕的是系統中的httpd進程數目會所以不斷增長，使得系統負載升高，甚至會致使服務器失去響應。

可是當你的服務器只是在處理動態網頁請求時，因爲用戶不多會瞬間請求多個動態網頁（通常都是打開頁面以後閱讀好半天才點下一頁），此時打開KeepAlive無異於浪費TCP鏈接數。哪麼什麼決定着咱們是否是要開啓KeepAlive的因素就很簡單的肯定出來了，就是說在用戶一個頁面請求中是否會向服務器發出多個HTTP的請求。

 

對於個人哪一個朋友，他們的服務器中有着動態應用，有着全部的圖片，我看了一下，估算他們的首頁中發出的請求類型爲如下幾種：text/html、text/css、application/octet-stream、text/javascript、image/gif、image/jpeg。一個首頁發出了181次請求（我看了全部的請求，注意全部的請求都是同一個域名）。這裏可能由應用程序生成的只有text/html和application/octet-stream，這種請求中text/html只有一次，而application/octet-stream也只有4次。哪麼關閉KeepAlive對他們有幫助嗎？個人回覆是沒有幫助，並且會讓服務器的服務質量更差！

 

若是是這樣的狀況，怎麼辦呢？個人建議以下： 

1.若是咱們每個頁面中只有一個請求是動態生成的，而180個（裏面可能有4個不是，不過不重要了）都是靜態的，哪麼應該將靜態與動態分開到兩個服務器上（一臺機器均可以）。將動態應用的KeepLive關閉，將靜態服務器的KeepLive打開。 

2.前端前部署四層交換或七層交換或緩存服務器，這樣會讓系統的擴展作起來，同時也可讓服務器的KeepLive打開時有更好的效果。

3.應該考慮優化下他們的apache了，據說一個進程有高達xxM的內存佔用，比較恐怖，在10M之內比較正常的說，不過這是一個option了。

 

http://www.phpv.net/

http://blog.csdn.net/21aspnet/article/details/7392923