Я немного запутался между различными MPM, предлагаемыми Apache: «worker», «event», «prefork» и т. д. Каковы основные различия между ними? И как я могу решить, какой из них будет лучше для развертывания?
Ответ 1
Существует множество модулей MPM (Multi-Processing Modules), но, безусловно, наиболее широко используемыми (по крайней мере, на платформах *nix) являются три основных: prefork, worker и event. По сути, они представляют собой эволюцию веб-сервера Apache и различные способы, которыми сервер был построен для обработки HTTP-запросов в рамках вычислительных ограничений того времени за свою долгую (с точки зрения программного обеспечения) историю.
prefork
Он выделяет несколько дочерних процессов для обслуживания запросов, и дочерние процессы обслуживают только один запрос за раз. Поскольку серверный процесс выполняется там, готовый к действию, и ему не нужно заниматься маршалингом потоков, он действительно быстрее, чем более современные потоковые MPM, когда вы имеете дело только с одним запросом за раз — однако одновременные запросы замедляются, поскольку им приходится ждать в очереди, пока освободится серверный процесс. Кроме того, пытаясь увеличить количество дочерних процессов prefork, вы легко поглотите значительное количество оперативной памяти. Вероятно, не рекомендуется использовать prefork, если только вам не нужен модуль, который не является потокобезопасным.
Используется, если вам нужны модули, которые завершаются при использовании потоков, например mod_php. Даже в этом случае рассмотрите возможность использования FastCGI и php-fpm.
Не используется, если ваши модули не будут завершаться при использовании потоков.
worker
mpm_worker использует потоки, что очень помогает при параллелизме. Worker порождает несколько дочерних процессов, которые, в свою очередь, порождают дочерние потоки; подобно prefork, некоторые свободные потоки держатся наготове, если это возможно, для обслуживания входящих соединений. Этот подход гораздо более щадящий для оперативной памяти, поскольку количество потоков не оказывает прямого влияния на использование памяти, как количество серверов в prefork. Он также намного проще справляется с параллелизмом, поскольку соединениям нужно просто ждать свободный поток (который обычно доступен), а не свободный сервер в prefork.
Используется, если вы работаете на Apache 2.2 или 2.4 и используете преимущественно SSL.
Не используется, если вы действительно не можете ошибиться, если только вам не нужен prefork для совместимости.
Однако обратите внимание, что треды прикрепляются к соединениям, а не к запросам, — это означает, что соединение keep-alive всегда держит поток, пока он не будет закрыт (что может занять много времени, в зависимости от вашей конфигурации). Вот почему у нас есть еще один вариант.
event
Структурно mpm_event очень похож на worker; он только что был переведен из статуса «experimental» в статус «stable» в Apache 2.4. Существенное отличие заключается в том, что он использует выделенный поток для работы с соединениями keep-alive и передает запросы дочерним потокам только тогда, когда запрос действительно был сделан (позволяя этим потокам освободиться сразу после завершения запроса). Это отлично подходит для параллельной работы клиентов, которые не обязательно все активны одновременно, но время от времени делают запросы, и когда клиенты могут иметь длительный тайм-аут keep-alive.
Исключение составляют соединения SSL; в этом случае он ведет себя идентично worker (коннектит данное соединение к данному потоку до тех пор, пока соединение не закроется).
Используется, если вы используете Apache 2.4 и вам нравятся потоки, но вам не нравится, когда потоки ждут простаивающих соединений. Всем нравятся потоки!
Не используется, если вы не на Apache 2.4 или вам нужен prefork для совместимости.
В современном мире slowloris, AJAX и браузеров, которые любят мультиплексировать 6 TCP-соединений (с keep-alive, конечно) с вашим сервером, параллельность является важным фактором для того, чтобы ваш сервер хорошо масштабировался. История Apache связала его в этом отношении, и хотя он все еще не дотягивает до уровня nginx или lighttpd в плане использования ресурсов или масштабирования, очевидно, что команда разработчиков работает над созданием веб-сервера, который все еще актуален в современном мире с высоким уровнем параллелизма запросов.
Ответ 2
По состоянию на февраль 2018 года, в документации Apache 2.4 для Event MPM говорится, что использование Apache в качестве прокси-сервера не позволит «улучшенной обработке соединений» с версии 2.4.24 работать так, как задумано. См. раздел «Ограничения».
Проблема заключается в том, что, будучи прокси, рабочий процесс не может определить, где конец ответа, и будет вынужден ждать, пока весь ответ не будет просмотрен, прежде чем вернуть управление слушателю.
По этой причине кажется, что использование модели Worker может быть лучшим вариантом для случаев, когда Apache используется в качестве прокси. Мне не совсем понятно, есть ли преимущества у событийной модели в среде прокси, но, возможно, они есть.
Ответ 3
В основном зависит от того, какие модули Apache вы хотите использовать. Я думаю, что worker обычно выбирается по умолчанию, но некоторые (более старые) модули требуют форка и зависят от prefork.
Если у вас нет предпочтений, я рекомендую вам выбрать наиболее предпочтительную зависимость из дистрибутива вашей ОС. Например, Ubuntu по умолчанию установит mpm-worker при установке Apache2.
Linux