Как вы справедливо заметили, есть несколько модулей MPM. К слову, аббревиатура расшифровывается как "Multi-Processing Modules", т.е. модули многопроцессорной обработки (извините за мой возможно не совсем точный английский). Из всего множества доступных MPM модулей в Linux системах, как правило, наиболее популярными являются те самые три, которые вы перечислили: prefork, worket и event.
prefork
Модуль mpm_prefork совместим практически со всем на свете. Он работает в любой конфигурации Хорошо или плохо - это другой вопрос. Его главное достоинство - переносимость и совместимость. То есть если вы не знаете с чего начать (например, ставите систему первый раз), то выбирая prefork скорее всего вы получите рабочую систему.
Этот модуль создает несколько дочерних процессов для обсуживания входящих запросов. При этом каждый дочерний процесс обрабатывает только один запрос. Поскольку такой подход является довольно таки экономным с точки зрения потребления ресурсов (дочерний процесс всегда создается для обработки конкретно поступающего запроса и не простаивает), то скорее всего prefork будет работать быстрее чем остальные MPM модули. Однако при этом быстродействие со стороны пользователя не такое уж оптимальное - т.к. параллельные запросы будут ожидать пока создадутся дочерние процессы, что бы обработать каждый из этих запросов. Если же вы позволите prefork создавать достаточно много дочерних процессов, это скажется на потреблении оперативки. Попросту говоря, ваш апач в таком случае сожрет всю доступную память и сделает это очень быстро.
Когда предпочесть prefork? Если вы используете какие то модули php или что то иное, что не работает нормально в множеством потоков.
Когда не использовать prefork? Если ваше приложение прекрасно поддерживает многопоточность. Потому что в таком случае prefork ничего полезного делать не будет, а будет только отнимать лишнюю память.
worker
mpm_worker использует многопоточность (threading) которая помогает обрабатывать большое количество одновременных запросов. Worker создает несколько дочерних процессов, которые в очередь начинают создавать threads (нити). Так же как и в случае с prefork, некоторые threads простаивают, ожидая входящие запросы. Однако такой подоход все же более экономичен с точки зрения потребления оперативной памяти. Так же не нужно ждать пока создаться новый процесс, потому что дочерние процессы очень быстро создают threads.
Когда предпочесть worker? Если у вас Apache 2.2 или 2.4 и если вы обслуживаете SSL (ваш сайт доступен только по https)
Когда не использовать worker? Практически такие случаи когда worker работает хуже чем prefork встречаются редко. Только если ваши модули плохо работают с многопоточностью.
event
mpm_event очень похож на worker. К слову сказать, event обрел официальный "стабильный статус" только в Apache 2.4. До этого он относился к "экспериментальным модулям", которые использовать рекомендовалось с большой осторожностью. Главное отличие event от всех остальных модулей (и от worker в частности) - модуль использует выделенный thread что бы обслуживать keep-alive соединения. При этом запрос передается на обработчик только когда соединение состоялось. Это отлично подоходит для многопоточных соединений, когда не все из этих соединений активны. Либо если клиенты, обращающиеся к вашему веб серверу, имеют большой keep-alive таймаут.
Стоит отметить что в случае с SSL (https), event ведет себя точно так же как и worker.
Когда предпочесть event? Если у вас Apache 2.4 и если вы не хотите иметь threads которые висят без дела, ожидая какой то активности.
Когда не использовать event? Только в случаях несовместимости с многопоточностью. Противопоказания точно такие же как и у worker.
