伺服器提供服務的方式
網路伺服器由於要同時為多個客戶提供服務，就必須使用某種方式來支援這種多任務的服務方式。一般情況下可以有三種方式來選擇，多進程方式、多線程方式及非同步方式。其中，多進程方式中伺服器對一個客戶要使用一個進程來提供服務，由於在作業系統中，產生一個進程需要進程記憶體複製等額外的開銷，這樣在客戶較多時的效能就會降低。為了克服這種產生進程的額外開銷，可以使用多線程方式或非同步方式。在多線程方式中，使用進程中的多個線程提供服務，由於線程的開銷較小，效能就會提高。事實上，不需要任何額外開銷的方式還是非同步方式，它使用非阻塞的方式與每個客戶通訊，伺服器使用一個進程進行輪詢就行了。
雖然非同步方式最為高效，但它也有自己的缺點。因為非同步方式下，多個任務之間的調度是由伺服器程式自身來完成的，而且一旦一個地方出現問題則整個伺服器就會出現問題。因此，向這種伺服器增加功能，一方面要遵從該伺服器自身特定的任務調度方式，另一方面要確保代碼中沒有錯誤存在，這就限制了伺服器的功能，使得非同步方式的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，或更高。
