Apache2 三種MPM對比分析

就最新版本的web伺服器apache（版本是apache 2.4.10，發布於2023年7月21日）來說，一共有三種穩定的mpm（multi-processing module，多程序處理模組）模式。它們分別是prefork，worker和event，它們同時也代表這apache的演變和發展。

檢視我們apache的模式，可以使用httpd -v命令來檢視：

編譯的時候，可以通過configure的引數來指定：

--with-mpm=prefork|worker|event

也可以編譯為三種都支援，通過修改配置來更換

--enable-mpms-shared=all

在httpd.conf中修改apache的多處理模式mpm可以通過（modules資料夾下，會自動編譯出三個mpm的so）：

#loadmodule mpm_prefork_module modules/mod_mpm_prefork.so

loadmodule mpm_worker_module modules/mod_mpm_worker.so

#loadmodule mpm_event_module modules/mod_mpm_event.so

1. prefork mpmprefork模式可以算是很古老但是非常穩定的apache模式。apache在啟動之初，就預先fork一些子程序，然後等待請求進來。之所以這樣做，是為了減少頻繁建立和銷毀程序的開銷。每個子程序只有乙個執行緒，在乙個時間點內，只能處理乙個請求。

優點：成熟穩定，相容所有新老模組。同時，不需要擔心執行緒安全的問題。（我們常用的mod_php，php的拓展不需要支援執行緒安全）

缺點：乙個程序相對占用更多的系統資源，消耗更多的記憶體。而且，它並不擅長處理高併發請求，在這種場景下，它會將請求放進佇列中，一直等到有可用程序，請求才會被處理。

apache的httpd.conf中的配置方式：

startservers

5minspareservers

5maxspareservers

10maxrequestworkers

250maxconnectionsperchild

2. worker mpmworker模式比起上乙個，是使用了多程序和多執行緒的混合模式。它也預先fork了幾個子程序（數量比較少），然後每個子程序建立一些執行緒，同時包括乙個監聽執行緒。每個請求過來，會被分配到1個執行緒來服務。執行緒比起程序會更輕量，因為執行緒通常會共享父程序的記憶體空間，因此，記憶體的占用會減少一些。在高併發的場景下，因為比起prefork有更多的可用執行緒，表現會更優秀一些。

有些人會覺得奇怪，那麼這裡為什麼不完全使用多執行緒呢，還要引入多程序？

原因主要是需要考慮穩定性，如果乙個執行緒異常掛了，會導致父程序連同其他正常的子執行緒都掛了（它們都是同乙個程序下的）。為了防止這場異常場景出現，就不

能全部使用執行緒，使用多個程序再加多執行緒，如果某個執行緒出現異常，受影響的只是apache的一部分服務，而不是整個服務。

優點：佔據更少的記憶體，高併發下表現更優秀。

中間幾乎沒有請求，需要一直等待到超時才會被釋放。如果過多的執行緒，被這樣佔據，也會導致在高併發場景下的無服務執行緒可用。（該問題在prefork模式

下，同樣會發生）

注：keep-alive的長連線方式，是為了讓下一次的socket通訊復用之前建立的連線，從而，減少連線的建立和銷毀的系統開銷。保持連線，會讓某個程序或者執行緒一直處於等待狀態，即使沒有資料過來。

apache的httpd.conf中的配置方式：

gt;

startservers

3minsparethreads

75maxsparethreads

250threadsperchild

25maxrequestworkers

400maxconnectionsperchild

3. event mpm這個是apache中最新的模式，在現在版本裡的已經是穩定可用的模式。它和worker模式很像，最大的區別在於，它解決了keep-alive 場景下，長期被占用的執行緒的資源浪費問題（某些執行緒因為被keep-alive，空掛在**等待，中間幾乎沒有請求過來，甚至等到超時）。event mpm中，會有乙個專門的執行緒來管理這些keep-alive型別的執行緒，當有真實請求過來的時候，將請求傳遞給服務執行緒，執行完畢後，又允許它釋放。這樣增強了高併發場景下的請求處理能力。

event mpm在遇到某些不相容的模組時，會失效，將會回退到worker模式，乙個工作執行緒處理乙個請求。官方自帶的模組，全部是支援event mpm的。

注意一點，event mpm需要linux系統（linux 2.6+）對epoll的支援，才能啟用。

還有，需要補充的是https的連線（ssl），它的執行模式仍然是類似worker的方式，執行緒會被一直占用，知道連線關閉。部分比較老的資料裡，說event mpm不支援ssl，那個說法是幾年前的說法，現在已經支援了。

apache的httpd.conf中的配置方式：

startservers

3minsparethreads

75maxsparethreads

250threadsperchild

25maxrequestworkers

400maxconnectionsperchild

三種模式下，我通過ab做了一下效能測試，在常規滿負載的場景下，並未發現有大的差異。

測試語句：

./ab -k -c 200 -n 200000

192.168.0.11/index.html

測試結果：

prefork：9556qps

worker ：11038qps

event ：10224qps

測試語句：

./ab -k -c 200 -n 200000

192.168.0.11/index.php（echo

"hello world

";）

測試結果：

prefork：6094qps

worker ：7411qps

event ：7089qps

就使用php而言，fastcgi和php-fpm是更推薦的使用模式。

Apache2 三種MPM對比分析

工廠模式三種工廠模式對比分析

對比分析元件邏輯復用的三種方案

流式大資料處理的三種框架對比分析

Apache2 三種MPM對比分析

工廠模式 三種工廠模式對比分析

對比分析元件邏輯復用的三種方案

流式大資料處理的三種框架對比分析

相關推薦

工廠模式三種工廠模式對比分析