多路處理模塊

多路處理模塊，Multi-Processing Modules，MPM

ApacheHTTP服務器被設計為一個強大的、靈活的能夠在多種平台以及不同環境下工作的服務器。不同的平台和不同的環境經常產生不同的需求，或是為了達到同樣的最佳效果而採用不同的方法。Apache憑藉它的模塊化設計很好的適應了大量不同的環境。這一設計使得網站管理員能夠在編譯時和運行時憑藉載入不同的模塊來決定服務器的不同附加功能。Apache2.0將這種模塊化的設計延伸到了web服務器的基礎功能上。這個版本帶有多路處理模塊(MPM)的選擇以處理網絡端口綁定、接受請求並指派子進程來處理這些請求。

將模塊化設計延伸到這一層次主要有以下兩大好處：

Apache可以更簡潔、更有效地支持各種操作系統。尤其是在mpm_winnt中使用本地網絡特性代替Apache1.3中使用的POSIX模擬層後，Windows版本的Apache現在具有更好的性能。這個優勢藉助特定的MPM同樣延伸到了其他各種操作系統。

服務器可以為某些特定的站點進行定製。比如，需要更好伸縮性的站點可以選擇象worker或event這樣線程化的MPM，而需要更好的穩定性和兼容性以適應一些舊的軟件的站點可以用prefork 。

從用户角度來看，MPM更像其他的Apache模塊。主要的不同在於：不論何時，必須有且僅有一個MPM被載入到服務器中。現有的MPM列表可以在模塊索引中找到。

MPM必須在編譯配置時進行選擇，並靜態編譯到服務器中。如果編譯器能夠確定線程功能被啓用，它將會負責優化大量功能。因為一些MPM在Unix上使用了線程，而另外一些沒有使用，所以如果在編譯配置時選擇MPM並靜態編譯進Apache，Apache將會有更好的表現。

可以在使用configure腳本時用 --with-mpm=NAME 選項指定MPM，NAME就是想使用的MPM的名稱。

一旦服務器編譯完成，就可以用 ./httpd -l 命令來查看使用了哪個MPM。這個命令將列出所有已經被編譯到服務器中的模塊，包括MPM。

下表列出了不同操作系統上默認的MPM。如果你在編譯時沒有進行選擇，這將是默認選擇的MPM。

beos 專門針對BeOS優化過的多路處理模塊(MPM)

event 一個標準workerMPM的實驗性變種。

mpm_netware Novell NetWare優化過的線程化的多路處理模塊(MPM)

mpmt_os2 專門針對OS/2優化過的混合多進程多線程多路處理模塊(MPM)

prefork 一個非線程型的、預派生的MPM

mpm_winnt 用於Windows NT/windows 2000/Windows XP/windows 2003 系列的MPM

worker 線程型的MPM，實現了一個混合的多線程多處理MPM，允許一個子進程中包含多個線程。

Preforking MPM 概述

一個非線程型的、預派生的MPM 。這個多路處理模塊(MPM)實現了一個非線程型的、預派生的web服務器，它的工作方式類似於Apache 1.3。它適合於沒有線程安全庫，需要避免線程兼容性問題的系統。它是要求將每個請求相互獨立的情況下最好的MPM，這樣若一個請求出現問題就不會影響到其他請求。

這個MPM具有很強的自我調節能力，只需要很少的配置指令調整。最重要的是將MaxClients設置為一個足夠大的數值以處理潛在的請求高峯，同時又不能太大，以致需要使用的內存超出物理內存的大小。

工作方式

一個單獨的控制進程(父進程)負責產生子進程，這些子進程用於監聽請求並作出應答。Apache總是試圖保持一些備用的(spare)或者是空閒的子進程用於迎接即將到來的請求。這樣客户端就不需要在得到服務前等候子進程的產生。

StartServers, MinSpareServers, MaxSpareServers, MaxClients指令用於調節父進程如何產生子進程。通常情況下Apache具有很強的自我調節能力，所以一般的網站不需要調整這些指令的默認值。可能需要處理最大超過256個併發請求的服務器可能需要增加MaxClients的值。內存比較小的機器則需要減少MaxClients的值以保證服務器不會崩潰。更多關於調整進程產生的問題請參見性能方面的提示。

在Unix系統中，父進程通常以root身份運行以便邦定80端口，而Apache產生的子進程通常以一個低特權的用户運行。User和Group指令用於設置子進程的低特權用户。運行子進程的用户必須要對它所服務的內容有讀取的權限，但是對服務內容之外的其他資源必須擁有儘可能少的權限。

MaxRequestsPerChild指令控制服務器殺死舊進程產生新進程的頻率。

worker mpm

支持混合的多線程多進程的多路處理模塊

概述

此多路處理模塊(MPM)使網絡服務器支持混合的多線程多進程。由於使用線程來處理請求，所以可以處理海量請求，而系統資源的開銷小於基於進程的MPM。但是，它也使用了多進程，每個進程又有多個線程，以獲得基於進程的MPM的穩定性。

控制這個MPM的最重要的指令是，控制每個子進程允許建立的線程數的ThreadsPerChild指令，和控制允許建立的總線程數的MaxClients指令。

工作方式

每個進程可以擁有的線程數量是固定的。服務器會根據負載情況增加或減少進程數量。一個單獨的控制進程(父進程)負責子進程的建立。每個子進程可以建立ThreadsPerChild數量的服務線程和一個監聽線程，該監聽線程監聽接入請求並將其傳遞給服務線程處理和應答。

Apache總是試圖維持一個備用(spare)或是空閒的服務線程池。這樣，客户端無須等待新線程或新進程的建立即可得到處理。初始化時建立的進程數量由StartServers指令決定。隨後父進程檢測所有子進程中空閒線程的總數，並新建或結束子進程使空閒線程的總數維持在MinSpareThreads和MaxSpareThreads所指定的範圍內。由於這個過程是自動調整的，幾乎沒有必要修改這些指令的缺省值。可以並行處理的客户端的最大數量取決於MaxClients指令。活動子進程的最大數量取決於MaxClients除以ThreadsPerChild的值。

有兩個指令設置了活動子進程數量和每個子進程中線程數量的硬限制。要想改變這個硬限制必須完全停止服務器然後再啓動服務器(直接重啓是不行的)，ServerLimit是活動子進程數量的硬限制，它必須大於或等於MaxClients除以ThreadsPerChild的值。ThreadLimit是所有服務線程總數的硬限制，它必須大於或等於ThreadsPerChild指令。這兩個指令必須出現在其他workerMPM指令的前面。

在設置的活動子進程數量之外，還可能有額外的子進程處於"正在中止"的狀態但是其中至少有一個服務線程仍然在處理客户端請求，直到到達MaxClients以致結束進程，雖然實際數量會很小。這個行為能夠通過以下禁止特別的子進程中止的方法來避免：

* 將MaxRequestsPerChild設為"0"

* 將MaxSpareThreads和MaxClients設為相同的值

一個典型的針對workerMPM的配置如下：

ServerLimit 16

StartServers 2

MaxClients 150

MinSpareThreads 25

MaxSpareThreads 75

ThreadsPerChild 25

在Unix中，為了能夠綁定80端口，父進程一般都是以root身份啓動，隨後，Apache以較低權限的用户建立子進程和線程。User和Group指令用於設置Apache子進程的權限。雖然子進程必須對其提供的內容擁有讀權限，但應該儘可能給予它較少的特權。另外，除非使用了suexec ，否則，這些指令設置的權限將被CGI腳本所繼承。

MaxRequestsPerChild指令用於控制服務器建立新進程和結束舊進程的頻率。

StartServers 指令

StartServers指令設置了服務器啓動時建立的子進程數量。

因為子進程數量動態的取決於負載的輕重，所有一般沒有必要調整這個參數。

MinSpareServers 指令

MinSpareServers指令設置空閒子進程的最小數量。

所謂空閒子進程是指沒有正在處理請求的子進程。如果當前空閒子進程數少於MinSpareServers ，那麼Apache將以最大每秒一個的速度產生新的子進程。

只有在非常繁忙機器上才需要調整這個參數。將此參數設的太大通常是一個壞主意。

MaxSpareServers 指令

MaxSpareServers指令設置空閒子進程的最大數量。

所謂空閒子進程是指沒有正在處理請求的子進程。如果當前有超過MaxSpareServers數量的空閒子進程，那麼父進程將殺死多餘的子進程。

只有在非常繁忙機器上才需要調整這個參數。將此參數設的太大通常是一個壞主意。如果將該指令的值設置為比MinSpareServers小，Apache將會自動將其修改成"MinSpareServers+1"。

MaxClients 指令

MaxClients指令設置了允許同時伺服的最大接入請求數量。

任何超過MaxClients限制的請求都將進入等候隊列，直到達到ListenBacklog指令限制的最大值為止。一旦一個鏈接被釋放，隊列中的請求將得到服務。

對於非線程型的MPM(也就是prefork)，MaxClients表示可以用於伺服客户端請求的最大子進程數量，默認值是256。要增大這個值，必須同時增大ServerLimit 。

對於線程型或者混合型的MPM(也就是beos或worker)，MaxClients表示可以用於伺服客户端請求的最大線程數量。線程型的beos的默認值是50。對於混合型的MPM默認值是16(ServerLimit)乘以25(ThreadsPerChild)的結果。因此要將MaxClients增加到超過16個進程才能提供的時候，必須同時增加ServerLimit的值。

MaxRequestsPerChild 指令

MaxRequestsPerChild指令設置每個子進程在其生存期內允許伺服的最大請求數量。到達MaxRequestsPerChild的限制後，子進程將會結束。如果MaxRequestsPerChild為"0"，子進程將永遠不會結束。

不同的默認值

在mpm_netware和mpm_winnt上的默認值是"0"。

將MaxRequestsPerChild設置成非零值有兩個好處：

* 可以防止(偶然的)內存泄漏無限進行，從而耗盡內存。

* 給進程一個有限壽命，從而有助於當服務器負載減輕的時候減少活動進程的數量。

注意：

對於KeepAlive鏈接，只有第一個請求會被計數。事實上，它改變了每個子進程限制最大鏈接數量的行為。

ThreadsPerChild 指令

這個指令設置了每個子進程建立的線程數。

子進程在啓動時建立這些線程後就不再建立新的線程了。如果使用一個類似於mpm_winnt只有一個子進程的MPM，這個數值要足夠大，以便可以處理可能的請求高峯。如果使用一個類似於worker有多個子進程的MPM，每個子進程所擁有的所有線程的總數要足夠大，以便可以處理可能的請求高峯。

對於mpm_winnt，ThreadsPerChild的默認值是64；對於其他MPM是25。

ThreadLimit 指令

這個指令設置了每個子進程可配置的線程數ThreadsPerChild上限。

任何在重啓期間對這個指令的改變都將被忽略，但對ThreadsPerChild的修改卻會生效。

使用這個指令時要特別當心。如果將ThreadLimit設置成一個高出ThreadsPerChild實際需要很多的值，將會有過多的共享內存被分配。如果將ThreadLimit和ThreadsPerChild設置成超過系統的處理能力，Apache可能無法啓動，或者系統將變得不穩定。該指令的值應當和ThreadsPerChild可能達到的最大值保持一致。

對於mpm_winnt，ThreadLimit的默認值是1920；對於其他MPM這個值是64。

注意：

Apache在編譯時內部有一個硬性的限制"ThreadLimit 20000"(對於mpm_winnt是"ThreadLimit 15000")，不能超越這個限制。

ServerLimit 指令

對於preforkMPM，這個指令設置了MaxClients最大允許配置的數值。

對於workerMPM，這個指令和ThreadLimit結合使用設置了MaxClients最大允許配置的數值。任何在重啓期間對這個指令的改變都將被忽略，但對MaxClients的修改卻會生效。

使用這個指令時要特別當心。如果將ServerLimit設置成一個高出實際需要許多的值，將會有過多的共享內存被分配。如果將ServerLimit和MaxClients設置成超過系統的處理能力，Apache可能無法啓動，或者系統將變得不穩定。

對於preforkMPM，只有在需要將MaxClients設置成高於默認值256的時候才需要使用這個指令。要將此指令的值保持和MaxClients一樣。

對於workerMPM，只有在需要將MaxClients和ThreadsPerChild設置成需要超過默認值16個子進程的時候才需要使用這個指令。不要將該指令的值設置的比MaxClients 和ThreadsPerChild需要的子進程數量高。

注意：

Apache在編譯時內部有一個硬限制"ServerLimit 20000"(對於preforkMPM為"ServerLimit 200000")。不能超越這個限制。