服務器提供服務的方式
網絡服務器由於要同時爲多個客戶提供服務，就必須使用某種方式來支持這種多任務的服務方式。一般情況下可以有三種方式來選擇，多進程方式、多線程方式及異 步方式。其中，多進程方式中服務器對一個客戶要使用一個進程來提供服務，由於在操作系統中，生成一個進程需要進程內存複製等額外的開銷，這樣在客戶較多時 的性能就會降低。爲了克服這種生成進程的額外開銷，可以使用多線程方式或異步方式。在多線程方式中，使用進程中的多個線程提供服務，由於線程的開銷較小， 性能就會提高。事實上，不需要任何額外開銷的方式還是異步方式，它使用非阻塞的方式與每個客戶通信，服務器使用一個進程進行輪詢就行了。
雖然異步方式最爲高效，但它也有自己的缺點。因爲異步方式下，多個任務之間的調度是由服務器程序自身來完成的，而且一旦一個地方出現問題則整個服務器就會出 現問題。因此，向這種服務器增加功能，一方面要遵從該服務器自身特定的任務調度方式，另一方面要確保代碼中沒有錯誤存在，這就限制了服務器的功能，使得異 步方式的Web 服務器的效率最高，但功能簡單。例如Unix 平臺上的thttpd 就是這樣的一種服務器，然而由於它提供的功能少，只能是滿足少部分人的需要。即便如此，thttpd 每隔一段時間還會出現一些問題，幸運的是，它出問題時從不是進入死循環，而是被操作系統殺死，這樣就可以使用一個shell 循環立即重啓動thttpd，從而基本不影響Web 服務。
由於多線程方式使用線程進行任務調度，這樣服務器的開發由於遵從標準，從而變得 簡單並有利於多人協作。然而多個線程位於同一個進程內，可以訪問同樣的內存空間，因此存在線程之間的影響，並且申請的內存必須確保申請和釋放。對於服務器 系統來講，由於它要數天、數月甚至數年連續不停的運轉，一點點錯誤就會逐漸積累而最終導致影響服務器的正常運轉，因此很難編寫一個高穩定性的多線程服務器 程序。微軟的IIS 就是使用的多線程方式，由於微軟聚集了相當多優秀程序員，所以IIS 基本上還是值得信賴的，當然我也遇到過很多系統管理員，他們根據經驗定期啓動所管理的NT 服務器，以預防不可預料的Web 服務停止現象。
多進程方式的優勢就在於穩定性，因爲一個進程退出的時候，操作系統會回收其佔用的資源，從而使它不會留下任何垃圾。即便程序中出現錯誤，由於進程是相互隔離的，那麼這個錯誤不會積累起來，而是隨着這個進程的退出而得到清除。
預生成進程方式的性能
由於Apache 是採用的多進程方式提供服務，爲了提高性能，Apache 採用了一種特別的方式，即預生成進程模型。分析多進程方式比其他兩種方式開銷大的主要原因，是對每一次客戶請求，都要生成一個子進程以便進行處理，因此爲 了避免這種開銷，可以使用預先生成的進程來提供服務，並且每個進程在提供一次服務之後也不會立即退出，而是仍然保留在系統中，等待下一次請求。
這裏就可以看出，在理想情況下，預先生成的多個進程可以全速回應相應數量的瀏覽器客戶請求，而沒有額外的性能開銷，因此就完全可以和線程或異步方式相媲美。然而在實際運行當中，由於預先生成的進程畢竟要佔用系統資源，如系統內存和CPU 處理能力，
這樣如果預先生成的進程超過需要，性能反而會降低。因此Apache 就採用了這樣的一種策略，在系統中保持一定的空閒進程，當空閒進程較少時就自動生成，當空閒進程較多時就讓一些進程退出。
由於Apache 採用這樣的預生成進程模型，就導致預先要生成多少進程、保留多少空閒進程、一個進程提供多少次服務等等成爲與性能密切相關的問題，然而，這些設置都是與具 體條件密切相關的。例如，越多的進程需要佔用越多的內存，所分得的CPU 處理時間就越少，因此係統的物理內存和CPU 處理能力就決定了進程的最大數量。而Apache 提供的基本配置是爲了適應大多數情況，在客戶請求較少時也不佔用過多資源，因此並不是最高性能的設置。而大多數Web 服務器測試的條件下，服務器的內存、CPU 處理能力都不是問題，甚至內存大到足以將所有要訪問的文檔都可以放在系統緩衝中，因而無須考慮磁盤處理能力，這種情況和實際應用完全不同。因此，SGI 的一位開發者通過調整設置，並使用他自己對Apache 代碼的一些改動，在同一個SGI Origin 200 服務器上使用SPECweb96 進行測試，調整後的服務器可以比原始設置提高10 倍的速度，當然這是針對SPECweb96 這個測試程序進行的調整，在實際使用中不可能會有這樣巨大的差別。這至少從側面說明了測試結果並不是絕對的。
此外，Apache 的另一個特點是它的功能特別豐富，而每種功能通常就需要進行特別的處理，這會影響Apache 的性能，然而對於具體的情況，卻不是每種特性都是必要的，因此可以通過減少這些功能來增加性能。此外，操作系統的調整對於增強Apache 的性能也是非常重要的。如何根據服務器的實際情況調整操作系統以及Apache 的參數，這些內容在Apache 的文檔中都有非常詳細的描述。這些文檔包含在每個Apache 安裝文件中，也可以直接從它的主頁得到。
Apache 2.0 展望
雖然Apache 服務器使用預生成進程的方式提高了服務器的性能，然而，程方式本身的不足仍然存在，隨着訪問數量的增多，進程方式比其他兩種方式需要消耗更多的內存和 CPU 處理能力，這就限制了單臺計算機提供更大負載的能力。如果在低端計算機上想服務更多的請求的話，使用異步方式的thttpd 更爲適合。例如，一臺512MB 內存雙CPU的Linux 服務器提供1000 個併發訪問時，其負載就會變得相當高，常常會由於內存用光而無法運行程序，這種情況是由於Linux 重視物理內存，不重視交換空間的原因，如果使用同樣配置的FreeBSD
作操作系統，情況會有所改變，然而此時由於需要進行內存交換，就無法達到最優性能了。
因此，這些情況下爲了支持更改的負載，完全採用進程方式就不太合適了，而應該利用線程節約資源的優點。
然而，在即將到來的Apache 2.0 中，一切都會變得更完美，Apache 2.0 將充分考慮到進程帶來的穩定性特徵，以及線程帶來高效率的特點。它會預生成多個進程，而每個進程中使用多個線程提供Web 服務。由於存在多個進程，即使一個進程死了也不會影響整個Web 服務。對於不支持進程的操作系統，如Windows，那麼就使用多個線程提供服務，反之也是一樣。然而，只有同時支持線程和進程的操作系統，才能充分利用 Apache 2.0帶來的穩定性和高負載能力。
事實上當前的Apache 並不是與線程無關，Windows 版本的Apache 是使用線程的，但按照Apache 文檔的說法，Windows 版本的Apache 性能並不好，主要原因是它在移植過程中是使用的Windows 的POSIX 子系統，而Windows 本身的有些特性效率更高。而在Apache2.0 中，使用了APR（Apache Portable Run-time）特性，這種特性對不同的操作系統提供了一個抽象層，以便Apache 能利用Windows 的一些非POSIX
的特性。
採用傳統的生成子進程的方式來提供服務的Apache，適合服務比較複雜的情況，但性能沒有單進程的服務器高，尤其在高負載的情況下更是如此。
對於重負載的Apache專業服務器，可以簡單的將以上SpareServers、StartServers、MaxClients四值設相同。
Squid是單進程的服務器，處理靜態頁面比Apache提高一個數量級。同樣，Windows平臺的IIS在靜態頁面上的處理性能也較Apache高几倍的性能（但不如Apache穩定）。
如有兩臺Apache服務器，第一個Apache服務器只提供靜態內容和代理服務，可將MaxClients設置較大。第二個Apache服務器要提供消耗處理器能力的動態網頁服務，要將MaxClients設置較小。
因此，應充分利用Apache的原理特性及工作平臺，合理地配置以下參數，在運行時動態調整，以使Apache達到最合理的狀態：
MaxKeepAliveRequests 100
# 一次連接可以進行的HTTP請求的最大請求次數（比如客戶一次連接中請求幾十個頁面）。
MinSpareServers 5
MaxSpareServers 10
# Apache預先生成多個空餘的子進程駐留系統中，用於處理客戶請求。兩個參數用於設置最小的空餘子進程數量及最多的空閒子進程數量。
StartServers 5
# 設置httpd啓動時啓動的子進程數量。這個參數應設置爲前兩個值之間的一個數值。小於或大於前兩個數值都沒有意義。
MaxClients 150
# 服務器支持的最大併發訪問的客戶數。
# 應根據服務器的物理內存及處理器動態調整。
MaxRequestsPerChild 30
# 每個子進程處理的服務請求次數。超過此值後，子進程副本退出，重新由原始的htttd進程中重新複製一個乾淨的副本，以提高系統的穩定性。
# 對於靜態頁面，產生的內存垃圾少，可設置爲2000，甚至更高；如服務器載入各種不同的功能模塊，產生內存垃圾多，可將此值降低。
# 對於高穩定的系統，如FreeBSD，可設成1000，或更高。
轉自：http://blog.tianya.cn/blogger/post_read.asp?BlogID=40003&PostID=4585547