Apache2 三種MPM對比分析

2022-03-16 05:43:58 字數 3988 閱讀 7737

就最新版本的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

0

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

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

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

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

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

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

下,同樣會發生)

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

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

gt;

startservers

3minsparethreads

75maxsparethreads

250threadsperchild

25maxrequestworkers

400maxconnectionsperchild

0

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

0

三種模式下,我通過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是更推薦的使用模式。

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

將構建過程封裝的好處不僅可以降低耦合如果某個產品構造方法相當複雜,使用工廠模式可以大大減少 重複。總而言之,簡單工廠模式就是讓乙個工廠類承擔構建所有物件的職責。呼叫者需要什麼產品,讓工廠生產出來即可。它的弊端也顯而易見 一是如果需要生產的產品過多,此模式會導致工廠類過於龐大,承擔過多的職責,變成超級...

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

一 復用元件邏輯的方案 1 通過高階元件hoc復用元件邏輯 import react from react 高階元件 const withmouse component handlemousemove event render onmousemove div return withmousecomp...

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

許多分布式計算系統都可以實時或接近實時地處理大資料流。本文將對三種apache框架分別進行簡單介紹,然後嘗試快速 高度概述其異同。apache storm 在storm中,先要設計乙個用於實時計算的圖狀結構,我們稱之為拓撲 topology 這個拓撲將會被提交給集群,由集群中的主控節點 master...