acceptmutex

apache 1.3.21和apache 2.0中引入了acceptmutex 指示符，該指示符給調節服務器的性能帶來了一個難得的機會。該指示符配置apache的accept()處理方式。在某些只有一個偵聽器的系統上是不需要接受阻塞的。這就叫single listen unserialized accept （slua）。可是，對那些具有多個偵聽器的配置或者在接受系統調用函數上（不管有多少個偵聽器）存在thundering herd問題的操作系統上，連接接受程序就必須進行串行化了。

covalent的sander temme對accept()阻塞策略進行了一定程度的性能分析。這份報告總結了apache 1.3.21在這一方面的有關調整策略，如下所示：

• irix的uslock (uslock)
• posix跨進程阻塞 (pthread)
• systemv semaphores (sysvsem)
• fcntl()阻塞(fcntl)
• flock()阻塞 (flock)
• os/2 semaphores (os2sem)
• tpf 阻塞 (tpfcore)
• none（無）

盡管采用acceptmutex none也是可能的，但是你的系統在這種配置下有可能受到thundering herd問題和死鎖的困擾。這些問題會導致服務器減慢處理速度乃至停止響應。none選項絕對不能用在實際系統上。在非正式的測試下，pthread鎖應該是最好的解決方案。然而，pthread跨進程阻塞并不是所有系統都可用的。

采用2.0版和線程（worker mpm）

apache 2.0有一個顯著的改進特性就是支持線程。某些操作系統，比如solaris，在采取線程技術的條件下可以顯著地改進系統性能。而其他操作系統，比如linux，其性能改進就可能并不是很顯著。

在采用apache 2.0的情況下，處理請求的策略已經理論化了，這就是所謂的mpm：多進程模式（multi process model）。而老一些的apache 1.3模式則以prefork mpm為代表，在unix平臺上就是默認mpm for 2.0 。在這種模式下有一個獨立的進程處理每一請求。可是，假如你編譯apache 2.0的時候帶 --with-mpm=worker 選項，那么服務器請求就會由線程來處理。這種方法在精心設計線程實現方案的情況下會大大降低操作系統處理請求的負載。

ssl會話緩存

如果你對apache 1.3或者在apache 2.0采用了mod_ssl補充插件（在在apache 2.0中則已經包含在內），那么你可以采用會話緩存提升系統性能。這種改進會顯著降低ssl連接負載。設置會話緩存有三種途徑：

• dbm (dbm)，這是一種在磁盤上存儲項目的常用格式（htpasswd可以dbm格式存儲密碼）
• 共享內存循環緩存（shm 或者shmcb）
• 共享內存哈系表（shmht）

在采用以上選項的時候需要指定文件路徑。在使用dbm變量的情況下，文件將被寫入磁盤。而對共享內存變量來說，文件將被用做操作系統優選共享內存機制的存儲備份。值得注意的是，大多數操作系統不允許共享內存段建立在通過網絡裝載（mount）的驅動器上，比如nfs等，所以必須給服務器提供文件路徑。

我們建議你采用共享內存，不過，在那些沒有共享內存的平臺上則不妨采用dbm方案。

• modssl.org
• apache.org

keepalivetimeout

假設某位用戶在閱讀網站上的某一網頁，然后它單擊某一導向站內另一網頁的鏈接。假如這一過程發生在keepalivetimeout 周期之內（默認為15秒），那么就不必創建新的tcp服務器連接。這樣做大大減少了計算機的負載。然而，在這一時間區域內服務器也不能處理更多的請求。keepalivetimeout周期過后，服務器才可以處理來自不同客戶機的最新請求。因此，你必須增加請求進程或者線程的數量以滿足空閑請求的需要。這個值應該進行仔細的調整以達到最佳狀態。

采用mod_status

采用mod_status檢查服務器負載情況可以從中獲得調整服務器性能的重要信息。

apachectl status命令是檢查服務器狀態的快捷途徑。假如該命令的輸出結果并沒有始終如一的顯示出可用的工作進程。那么最好增大minspareservers或者minsparethreads值（在apache 2.0采用線程化mpm的情況下）。同時你可能還需要增大maxclients值。

小結

你完全可以采用本文提出的技巧使服務器的性能最大化同時維持網站的正常運行。