MPM – Multi-Processing Module, мож­но пере­ве­сти как “Модуль муль­ти­про­цес­со­вой обра­бот­ки”
В насто­я­щее вре­мя исполь­зу­ет­ся 2 основ­ных вари­ан­та MPM – это Worker и PreFork. Так­же, име­ет­ся срав­ни­тель­но новый модуль – Event

Apache MPM PreFork запус­ка­ет по отдель­но­му про­цес­су на каж­дый запрос. Ина­че гово­ря, каж­дый про­цесс одно­вре­мен­но обра­ба­ты­ва­ет толь­ко 1 поток (thread) на одно соеди­не­ние. Т.к. PreFork зара­нее созда­ет опре­де­лен­ное коли­че­ство про­цес­сов, кото­рые не тре­бу­ют вре­ме­ни на отдель­ный вызов при поступ­ле­нии запро­са к сер­ве­ру и не нуж­да­ют­ся в выпол­не­нии мар­ша­лин­га (в тех­но­ло­гии ORPC – про­цесс упа­ков­ки запро­са, вклю­чая пара­мет­ры, в стан­дарт­ный фор­мат, при­год­ный для пере­да­чи по сети) во вре­мя его обра­бот­ки, то такой вари­ант явля­ет­ся наи­бо­лее быст­ро­дей­ству­ю­щим, по срав­не­нию с дру­ги­ми MPM. Одна­ко, такой при­рост про­из­во­ди­тель­но­сти име­ет­ся толь­ко в слу­чае, когда одно­вре­мен­но посту­па­ет неко­то­рое огра­ни­чен­ное коли­че­ство одно­вре­мен­ных запро­сов, т.к. каж­дый из них дол­жен ждать, пока про­цес­сор смо­жет их обра­бо­тать. Кро­ме того, попыт­ки уве­ли­чить коли­че­ство одно­вре­мен­но запус­ка­е­мых про­цес­сов спо­соб­но серьез­но повли­ять на исполь­зу­е­мую сер­ве­ром память.

Apache MPM worker – исполь­зу­ет мно­го­по­точ­ную систе­му обра­бот­ки запро­сов, что улуч­ша­ет обра­бот­ку боль­шо­го коли­че­ства соеди­не­ний. MPM Worker запус­ка­ет несколь­ко про­цес­сов, кото­рые, в свою оче­редь, запус­ка­ют несколь­ко пото­ков (threads). Эти “дочер­ние пото­ки”, по ана­ло­гии с про­цес­са­ми MPM PreFork, ожи­да­ют вхо­дя­щих кли­ент­ских запро­сов. Такой под­ход явля­ет­ся менее ресур­со­ём­ким в плане потреб­ле­ния опе­ра­тив­ной памя­ти сер­ве­ра, в отли­чии от про­цес­сов PreFork. Так же, улуч­ша­ет­ся обра­бот­ка боль­шо­го коли­че­ства одно­вре­мен­ных запро­сов, т.к. в отли­чии от  PreFork запро­су необ­хо­ди­мо толь­ко полу­чить сво­бод­ный поток, кото­рый как пра­ви­ло есть, что поз­во­ля­ет сэко­но­мить ресур­сы сервера.

К недо­стат­кам MPM Worker отно­сит­ся его отно­си­тель­ная неста­биль­ность, по срав­не­нию с PreFork, т.к. про­бле­мы в одном про­цес­се могут затро­нуть дру­гие соединения.Кроме того, имей­те вви­ду, что Worker свя­зы­ва­ет каж­дое keep-alive соеди­не­ние с пото­ком, а не с запро­сом, и в таком слу­чае каж­дый поток может выпол­нят­ся зна­чи­тель­ное вре­мя, пока соеди­не­ние не будет окон­ча­тель­но разорвано.

Apache MPM Event. По прин­ци­пу рабо­ты он очень похож на MPM Worker.  Глав­ное отли­чие Event от Worker в том, что он под­дер­жи­ва­ет выде­лен­ный поток для каж­до­го уста­нов­лен­но­го соеди­не­ния, и пере­да­ет дочер­ним пото­кам запрос толь­ко после того, как он был непо­сред­ствен­но сде­лан. И сра­зу же после обра­бот­ки это­го запро­са – поток осво­бож­да­ет­ся для выпол­не­ния сле­ду­ю­ще­го запро­са. Такой вари­ант отлич­но под­хо­дит для кли­ен­тов, кото­рые дела­ют не частые запро­сы, но под­дер­жи­ва­ют дол­гие keep-alive соеди­не­ния с сервером.

Узнать, какой тип MPM исполь­зу­ет­ся в уста­нов­лен­ном Apache мож­но любой из команд:

# apachectl -t -D DUMP_MODULES | grep mpm
mpm_prefork_module (static)

или

# httpd -V | grep mpm
-D APACHE_MPM_DIR=”server/mpm/prefork”

Для изме­не­ния режи­ма рабо­ты, нуж­но в файле:

nano /etc/sysconfig/httpd

рас­ком­мен­ти­ро­вать строчку: