Apache 打開網頁的時候等待時間過長的解決方案

服務器搭建後常常在打開頁面的時候，等待很長時間，有時候，都超過一分鐘了，而後才能打開，可是打開後，速度又很快，休息一會再點擊，又會很慢了，遇到了這種問題很頭疼，因爲不是專業作服務器配置的，因此剛開始沒有找到好的解決辦法，只能一點點去測試了

首先嚐試了，給Apache開啓Gzip功能，減小數據的傳輸，優化網絡，可是效果不明顯，仍是同樣的慢，如何開啓GZIP，請查看上一篇日誌，Apache開啓GZIP。

而後嘗試，加入緩存功能，也基本上沒有效果，在頁面中加入緩存，不在這裏進行介紹了，能夠查看相關資料。

通過仔細觀察，發現是打開網頁的時候，一直在等待xxx.xxx.com響應，證實不是GZIP或者是緩存的問題，應該是服務器響應的問題，在這個想到的，第一個是服務器能同時承受的鏈接數設置的過少，第二個是服務器已有資源已用完，只能等待釋放新的資源。

在網上查找資料，開始修改上對於服務器的一些設置，先設置Apache的MPM模塊（多路處理模塊），設置模塊中的相關選項，由於是使用的Windows操做系統，因此設置的模塊爲：<IfModule mpm_winnt_module>，此模塊是在Windows服務器下使用的，該多路處理模塊(MPM)是Windows NT上的默認值。它使用一個單獨的父進程產生一個單獨的子進程，在這個子進程中輪流產生多個線程來處理請求。

在此設置爲：

ThreadStackSize 8388608   #用來控制堆棧大小

默認：NetWare上爲65536，其餘平臺上等於操做系統默認值
這個指令用來設置處理客戶端鏈接（包括調用模塊以協助處理）的線程容許使用的最大棧尺寸（字節）。
大多數狀況下，操做系統默認的棧尺寸很合理。可是在某些狀況下，須要調整這個值：
在默認棧尺寸較小的平臺上(好比HP-UX)，Apache可能會在使用一些須要較大棧尺寸的第三方模塊時崩潰。這樣的問題能夠經過將ThreadStackSize設置爲一個較大的值來解決。這種調整應當僅僅在第三方模塊提供者明確要求的狀況下才須要，或者是您經過診斷肯定是因爲棧空間過小而致使崩潰。
在某些平臺上，若是默認的棧空間大於服務器運行所需空間，那麼將ThreadStackSize值下降到小於操做系統默認值可讓每一個進程中容許生成的最大線程數量增長。這種類型的調整應該僅在測試環境中使用，而且對全部服務器進程進行充分的測試，由於處理某些罕見的請求須要較大的棧空間。一個很小的服務器配置變化就有可能使得當前的ThreadStackSize設置變得不合適。

ThreadsPerChild 350 每一個子進程的服務線程數目

每一個子進程的服務線程數目
MaxConnectionsPerChild 10000 最大鏈接數的一個服務器進程服務

最大鏈接數的一個服務器進程服務

一些其它的參數

# StartServers:　　初始數量的服務器進程開始

# MinSpareThreads:　　最小數量的工做線程,保存備用

# MaxSpareThreads:　　最大數量的工做線程,保存備用

# ThreadsPerChild:　　固定數量的工做線程在每一個服務器進程

# MaxRequestWorkers:　　最大數量的工做線程

# MaxConnectionsPerChild:　　最大鏈接數的一個服務器進程服務

 

因爲是在進行測試，因此所設置數量，並不提供準確的值，僅爲解決問題頁來，具體數值大小，請參考自身設計

 

之後設置完成後，問題依然沒有解決，

而後設置服務的鏈接超超等，在extra/httpd-default.conf 文件，須要在httpd.conf中打開此註釋

修改KeepAlive 

KeepAlive指的是保持鏈接活躍

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

表示單個進程的最大請求數

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

KeepAliveTimeout的設置說明：
Apache在關閉持久鏈接前等待下一個請求的秒數。一旦收到一個請求，超時值將會被設置爲Timeout指令指定的秒數。
對於高負荷服務器來講，KeepAliveTimeout值較大會致使一些性能方面的問題：超時值越大，與空閒客戶端保持鏈接的進程就越多。

MaxRequestsPerChild 表示單個進程的最大請求數

以上設置完成後，重啓服務器，測試後狀況有所改觀，可是仍是常常出現等待響應。

再查找資料，見到有說人到，須要根據協議類型對監聽Socket進行優化。

Accept Filter 接收以後對信息進行一個過濾，有介紹說是反向一個代理，具體也不清楚，看到了，果斷試一下。

AcceptFilter http none

AcceptFilter https none

 

以後重啓服務，而後進行測試，通過差很少4個小時的測試，沒有出現正在等待響應的問題，至此問題基本解決，同時也開啓了GZIP的功能，而且也進行了一些其它的優化。一直困擾多天的問題，終於煙消雲散了，至於其它的問題，只能邊發現問題，邊解決問題了。