服務器搭建后經常在打開頁面的時候，等待很長時間，有時候，都超過一分鍾了，然后才能打開，但是打開后，速度又很快，休息一會再點擊，又會很慢了，遇到了這種問題很頭疼，由於不是專業做服務器配置的，所以剛開始沒有找到好的解決辦法，只能一點點去測試了
首先嘗試了，給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的功能，並且也進行了一些其它的優化。一直困擾多天的問題，終於煙消雲散了，至於其它的問題，只能邊發現問題，邊解決問題了。