Есть целый ряд модулей MPM (Мульти-Модули обработки), но на сегодняшний день наиболее широко используется (по крайней мере , на * NIX платформах) являются тремя основными из них: prefork, worker, и event. По сути, они представляют собой эволюцию веб-сервера Apache и различные способы, которыми был построен сервер для обработки HTTP-запросов в рамках вычислительных ограничений времени в течение его длинной (с точки зрения программного обеспечения) истории.
mpm_preforkэто .. хорошо .. это совместимо со всем. Он обслуживает несколько дочерних процессов для обслуживания запросов, и дочерние процессы обслуживают только один запрос за раз. Поскольку там находится серверный процесс, готовый к действию, и ему не нужно иметь дело с маршалингом потоков, он на самом деле быстрее, чем более современные многопоточные MPM, когда вы работаете только с одним запросом за раз - но одновременные запросы страдают, так как они вынуждены ждать в очереди, пока серверный процесс не будет свободным. Кроме того, пытаясь увеличить количество дочерних процессов prefork, вы легко отнимите серьезную оперативную память.
Вероятно, не рекомендуется использовать prefork, если вам не нужен модуль, который не является потокобезопасным.
Используйте if: Вам нужны модули, которые ломаются при использовании потоков, например mod_php. Даже тогда рассмотрите возможность использования FastCGI и php-fpm.
Не используйте if: Ваши модули не прерываются в потоке.
mpm_workerиспользует многопоточность - это большая помощь для параллелизма. Рабочий раскручивает некоторые дочерние процессы, которые, в свою очередь, раскручивают дочерние потоки; По аналогии с prefork, некоторые резервные потоки, если это возможно, остаются готовыми для обслуживания входящих соединений. Этот подход намного лучше в оперативной памяти, поскольку счетчик потоков не имеет непосредственного отношения к использованию памяти, как подсчет серверов в prefork. Кроме того, он гораздо проще обрабатывает параллелизм, поскольку соединениям просто нужно ждать свободного потока (который обычно доступен) вместо резервного сервера в prefork.
Используйте if: вы используете Apache 2.2 или 2.4 и используете в основном SSL.
Не используйте if: вы действительно не ошибетесь, если вам не нужен prefork для совместимости.
Однако обратите внимание, что шаги присоединяются к соединениям, а не к запросам - это означает, что соединение keep-alive всегда удерживает поток до его закрытия (что может быть долгим, в зависимости от вашей конфигурации). Вот почему у нас есть ..
mpm_eventочень похож на рабочий, структурно; он только что был переведен из «экспериментального» в «стабильный» статус в Apache 2.4. Большая разница состоит в том, что он использует выделенный поток для работы с поддерживаемыми соединениями и передает запросы дочерним потокам только тогда, когда запрос фактически сделан (что позволяет этим потокам освободиться сразу же после завершения запроса). Это отлично подходит для одновременной работы клиентов, которые не обязательно все активны одновременно, но время от времени делают запросы и когда клиенты могут иметь длительный тайм-аут активности.
Исключением здесь являются SSL-соединения; в этом случае он ведет себя идентично рабочему (приклеивая данное соединение к данному потоку, пока соединение не закроется).
Используйте if: вы на Apache 2.4 и любите потоки, но вам не нравится, когда потоки ожидают незанятых соединений. Все любят темы!
Не используйте if: вы не используете Apache 2.4 или вам нужен prefork для совместимости.
В современном мире Slowloris , AJAX и браузеров, которым нравится мультиплексировать 6 TCP-соединений (с поддержкой keep-alive) на ваш сервер, параллелизм является важным фактором, способствующим хорошему масштабированию и масштабированию вашего сервера. В этом отношении история Apache связала его, и, хотя она по-прежнему не соответствует стандартам nginx или lighttpd с точки зрения использования ресурсов или масштаба, очевидно, что команда разработчиков работает над созданием веб-сервера, который по-прежнему актуален в сегодняшнем мире с высоким уровнем запросов-параллелизма.