apache的mpm的幾種模式

MPM(多路處理模塊)
event 模式

serverlimit 50 表示服務器容許開啓的最大進程數量
startservers 初始開啓進程 3
minsparethreads 最小閒置進程 5
maxsparethreads 最大閒置進程 10

apache必需要要保證有必定的閒置緩衝進程來給本身的訪問負載留有後牆，一開始訪問有2個進程佔用（初始進程），那麼閒置的進程就是1，爲了保險起見萬一別的人訪問我留有後牆，apache規定了最小閒置進程就是5，那麼apche父進程（root用戶建立的父進程）第一秒增長1個進程數（閒置進程也叫子進程daemon用戶建立），第二秒會增長2個進程數，第三秒會增長4個進程數，直到保證本身的閒置進程大於規定的minsparethreads5便可就中止增長，這是一個動態的過程，隨着訪問量增多，那麼進程數會開的愈來愈多，直到不少人忽然下線，潮水退去，那麼假設最後我開啓了100個進程，退了20個進程，那麼是否是在那一瞬間20個進程限制，的確，知足了大於最小閒置進程數要求，可是萬一100個全退，就是100個閒置進程，因此還有一個最大閒置進程，大於最大閒置進程我就關，反正閒置的進程，apache本身會運算反正後牆區間必定控制在最小閒置進程和最大閒置進程之間。

event工做模式最典型的方式是進程裏面包裹多條線程，默認是25，真正執行代碼的是線程，因此event工做模式適用處理於apache的高負載高併發狀況下，並且event還有一個特色就是解決異步非租塞問題，什麼意思呢，就是不少人連着這個網頁，可是什麼都不點都不請求就等着，一直佔用那個keepalive保持鏈接，直到保持鏈接超時，這樣一直佔着就會致使資源浪費，event工做模式就是解決了這個問題，每一個進程中都有一個keepalive線程去處理，處理我這個進程中客戶端的keepalive掛着****那我來處理你，若是你訪問鼠標點一點請求了，那麼由同一進程中隔壁負責請求處理的正常線程去處理你，你點了一段時間又不點了，那麼仍是回到keepalive線程中 ，一個負責處理請求的線程對接一個客戶端

maxrequestworkers 容許同一時間服務器同時響應工做的線程數量，一個線程對應一個客戶端，超過請求數就會排隊，好比apache運行了20個進程，每一個進程運行24個服務線程，服務器能夠同時進行24*20=480個併發的http請求，前480個都在線，你是第481個你可能就須要排隊了哦，因此雙十一爲何會排隊，由於你的服務器線程就那麼多，請求總有個上限限制，你網速很差，進去慢就要排隊，因此最好的解決辦法是網速要快，插網線帶寬足夠高用電腦搶，一直點，不用擔憂服務器死機，
maxconnnectionperchild 每一個子進程在其生存週期內容許處理的最大http請求總數，設置爲0就是這個進程永遠不會中止，http請求沒有上限，這樣會消耗內存的資源，術語叫作php的內存泄漏，全部通常都會有個上限，好比到總數到20000結束，到了就在從新開一個進程

event模式優勢：多進程，總有閒置進程，進程中多子線程，是進程中有線程處理http請求，而且有專門的線程處理keepalive客戶端佔據資源不訪問題，能夠實現和客戶端不點擊和點擊的異步非阻塞，適用於高併發瀏覽量大的狀況下開啓此模式，進程開的少，都是進程裏面有線程嗎，因此內存佔用比也會低一些
event模式條件：
須要linux操做系統支持epoll，2.6版本的linux都支持，多老纔會不支持，
其次官方自帶的模塊event模式下的apache是兼容的，若是是第三方模塊那可能得考慮一下了，event模式下的apache可能不支持
而後是https的鏈接，一個線程對應一個請求，安全性鏈接嗎，若是處理https的鏈接會退回到worker模式，沒有keepalive專門的線程去管不點擊訪問的客戶端。

worker模式
worker模式的升級版就是event模式，不一樣之處在於進程中沒有專門子線程去處理keepalive的保持鏈接，一個線程完徹底全對接一個客戶端，沒法解決長鏈接資源被佔用問題，沒法實現服務線程和保持線程的異步非阻塞其他的沒有任何區別。
event和worker的缺點：但worker和event也由不完善的地方，假如一個線程崩潰，整個進程就會連同其任何線程一塊兒"死掉".因爲線程共享內存空間，因此一個程式在運行時必須被系統識別爲每 個線程都是安全的，否則容易出現多臺客戶端掉線的問題，嚴重些還會致使服務奔潰，並且不少php模塊event模式也不支持。

prefork模式
prefork模式使用多個子進程，一個進程裏面只有一個線程，在大多數平臺上，prefork模式比worker和event模式更高效安全成熟速度快，由於一個進程奔潰不會影響其餘線程其餘客戶端請求，並且正是一個進程處理一個線程，專門對接，高效迅速，不須要線程之間共享內存，因此有專門物理內存管理，內存大，不也快嗎，其次不須要擔憂第三方模塊的線程兼容性問題，apache在event工做模式下有的識別不了第三方模塊，會退到work模式，因此對於一些中小型網站prefork模式更成熟穩定高效速度快
總結：好比，須要更好伸縮性的能夠選擇象worker或event這樣線程化的MPM，而須要更好的穩定性和兼容性以適應一些舊的軟件能夠用prefork 。

event模式配置測試及ab壓力測試
源碼編譯安裝執行configure腳本時指定工做模式

若是在已經編譯好切換，能夠看出mpm配置文件三種模式都有，可是切換centos彷佛很難，Redhat的切換方式以下

咱們就以event模式配置爲例吧，prefork這個最穩定的模式也是同樣！

ab壓力測試

apache沒優化前

要注意一下，這個-n參數至關因而tcp的請求，一次就是至關於讓多少個客戶機去鏈接這個服務器，而這個-c至關因而httpd的併發請求，至關於一個客戶端發出http請求數，因此最終的請求個數是n*c，這是測試服務器性能壓力的有效方式

接下來咱們來進行調優，初始進程調大，閒置子進程擴大，每一個子進程的線程數增長，每一個進程數容許處理的http請求數增長，咱們來看一下服務器總計處理這些請求timetaken的處理時間

現實生活中用的不少壓力性能測試工具都是第三方的，八九種，生產中apache自帶的ab壓測用的比較少，比較知名開源的的是LoadRunner、Apache JMeter等等

更好的理解prefork、worker、event具體連接以下
http://www.javashuo.com/article/p-cuturkmu-y.html