Apache 性能最優化分析(6)_Windows教程

3) 單socket中的accept串行化

　　以上言及的方案對多socket服務器是相當不錯的，但只有一個socket的情況又如何呢？理論上，由于在連接請求到來之前所有子進程將阻塞在accept中，單個socket不會產生上述種種問題。但實際上，上述非阻塞解決方案所帶來的"回旋（spinning）"問題在這里只不過被掩蓋起來了。在絕大多數TCP協議棧的實現中，一個接請求到來時內核將喚醒所有阻塞在accept中的進程。它們之一將得到此請求并返回用戶空間，其余的進程將返回內核重新休眠。這將帶來與多socket非阻塞解決方案相同的資源浪費。

　　由于這點原因，我們發現如果為socket串行化，許多系統表現得更"友好"--即使是一個socket的情況。這是單個socket串行化作為絕大多數情況的缺省配置的原因。在Linux上不甚精確的（Linux 2.0.30 / 雙Pentium Pro 166 w / 128Mb內存）實驗表明，對每次請求而言，串行化的單個socket僅比沒有串行化的socket損失不到3%的性能。但未串行化的socket顯示出每次連接請求100毫秒的延時。這也可能僅僅由于過長的通訊距離造成的。如果您不想串行化單個socket，可以定義宏SINGLE_LISTEN_UNSERIALIZED_ACCEPT。這樣，僅有一個socket的服務器將不會串行化。

　　4) 延遲關閉（Lingering Close）

　　就象draft-ietf-http-connection-00.txt第8節討論的那樣，為了使服務器能夠可靠地實現HTTP協議，有必要獨立地關閉每個方向上的通訊（每個TCP連接有兩個方向，每個方向是分別獨立的）。這個事實往往被其他服務器所忽視，而Apache 1.2就已經正確地處理了。

　　當這個特性增加到Apache中時卻在許多版本的Unix中引起了問題。這是TCP規范的短見造成的--它沒有聲明FIN_WAIT_2有超時，但也沒有阻止這樣的實現。在沒有超時的系統中，Apache 1.2將導致許多socket將永遠處于FIN_WAIT_2的狀態。這可以簡單地用打最新TCP/IP補丁的方法避免。然而在提供商從不發行補丁的系統上（也就是SunOS4--雖然得到源代碼許可證的人可以自己打補丁），我們決定不直接使用這一特性。