httpd的三種模式比較

標籤：ref   nic   多個   jic   啟用   類型   防止   不能   進程   

查看你的httpd使用了哪種模式：

/usr/local/apache2/bin/httpd -V |grep ‘Server MPM‘

 

使用哪種模式，需要在編譯的時候指定

--with-mpm=prefork|worker|event

 

當然也可以編譯的時候，讓三者都支援：

--enable-mpms-shared=all

 

然後在設定檔中，修改

LoadModule mpm_worker_module modules/mpd_mpm_worker.so

 

2.2版本預設為worker，2.4版本預設為event

 

再來比較一下三種模式的差異

 

1 prefork

prefork模式可以算是很古老但是非常穩定的Apache模式。Apache在啟動之初，就預先fork一些子進程，然後等待請求進來。之所以這樣做，是為了減少頻繁建立和銷毀進程的開銷。每個子進程只有一個線程，在一個時間點內，只能處理一個請求。
優點：成熟穩定，相容所有新老模組。同時，不需要擔心安全執行緒的問題。（我們常用的mod_php，PHP的拓展不需要支援安全執行緒）
缺點：一個進程相對佔用更多的系統資源，消耗更多的記憶體。而且，它並不擅長處理高並發請求，在這種情境下，它會將請求放進隊列中，一直等到有可用進程，請求才會被處理。

 

2 worker

worker模式比起上一個，是使用了多進程和多線程的混合模式。它也預先fork了幾個子進程（數量比較少），然後每個子進程建立一些線程，同時包括一個監聽線程。每個請求過來，會被分配到1個線程來服務。線程比起進程會更輕量，因為線程通常會共用父進程的記憶體空間，因此，記憶體的佔用會減少一些。在高並發的情境下，因為比起prefork有更多的可用線程，表現會更優秀一些。
有些人會覺得奇怪，那麼這裡為什麼不完全使用多線程呢，還要引入多進程？
原因主要是需要考慮穩定性，如果一個線程異常掛了，會導致父進程連同其他正常的子線程都掛了（它們都是同一個進程下的）。為了防止這場異常情境出現，就不能全部使用線程，使用多個進程再加多線程，如果某個線程出現異常，受影響的只是Apache的一部分服務，而不是整個服務。

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

缺點：必須考慮安全執行緒的問題，因為多個子線程是共用父進程的記憶體位址的。如果使用keep-alive的長串連方式，某個線程會一直被佔據，也許中間幾乎沒有請求，需要一直等待到逾時才會被釋放。如果過多的線程，被這樣佔據，也會導致在高並發情境下的無服務線程可用。（該問題在prefork模式下，同樣會發生）

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

3  event

這個是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，那個說法是幾年前的說法，現在已經支援了。

httpd的三種模式比較