Почему Apache Event MPM работает плохо?

Событие MPM - это не совсем тот же дизайн, что и Nginx, но он был явно разработан, чтобы сделать keepalives более гибким и быстрее отправлять статические файлы. Я понимаю, что Event MPM является немного неправильным, потому что:

Хотя соединение передается в kqueue/epoll,
некоторые очень важные модули, такие как mod_gzip и mod_ssl, будут блокировать/потреблять поток до тех пор, пока не будет выполнен ответ,
и это проблема для больших файлов, но, вероятно, не для PHP-сгенерированных HTML-документов и т.д.

К сожалению, Apache продолжает терять рыночные позиции, и большинство эталонных тестов ущемляют событие MPM. Являются ли эталонные ошибки ошибочными, или это событие MPM действительно плохо влияет на Nginx? Даже с этими ограничениями, при нормальном трафике (не вредоносных) и меньших файлах, он должен быть несколько конкурентным с Nginx. Например, он должен быть конкурентным, служащим PHP-сгенерированными документами через php-fpm на медленных соединениях, потому что документ будет буферизован (даже если он был ssl'd и gzip'd) и отправлен асинхронно. Как SSL, так и не SSL-соединения с использованием сжатия или не должны работать значимо иначе, чем в Nginx при такой нагрузке.

Так почему же он не светит в разных тестах? Что с этим не так? Или что не так с бенчмарками? Является ли основным сайтом его использование в качестве апелляции к полномочиям, которые он может выполнять?

Ответ 1

Это медленнее, чем nginx, потому что Apache с событием MPM (очень) примерно эквивалентен управляемому событиями HTTP-прокси (nginx, лак, haproxy) перед Apache с рабочим MPM. Событие - это рабочий, но вместо того, чтобы передавать каждое новое соединение потоку в течение его жизненного цикла, потоки MPM события передают соединение второму потоку, который толкает его в очередь или закрывает его, если keep-alive выключен или истек.

Реальное преимущество события над работником - это использование ресурсов. Если вам необходимо поддерживать 1000 параллельных соединений, рабочим MPM требуется 1000 потоков, в то время как MPM событий может пройти 100 активных потоков и 900 незанятых соединений, управляемых в очереди событий. Событие MPM будет использовать часть ресурсов рабочего MPM в этом гипотетическом, но недостаток все еще существует: каждый из этих запросов обрабатывается отдельным потоком, который должен быть запланирован ядром, и как таковой будет нести стоимость контекст переключения.

С другой стороны, мы имеем nginx, который сам использует модель события в качестве своего планировщика. Nginx просто обрабатывает столько работы над каждым соединением, сколько может, прежде чем переходить к следующему. Никакого дополнительного переключения контекста не требуется.

В одном случае, когда событие MPM действительно сияет, нужно обрабатывать установку, в которой у вас тяжелое приложение, запущенное в Apache, и для экономии ресурсов потоков, которые простаивают во время keep-alive, вы должны развернуть прокси-сервер (например, как nginx) перед apache. Если ваш внешний интерфейс не обслуживал другую цель (например, статический контент, проксирование на другие серверы и т.д.), Событие MPM обрабатывает, что использует случай красиво и устраняет необходимость в прокси.

Ответ 2

Для меня доминирующие оперативные различия заключаются в том, что в случае:

обработчики (плагины, ответственные за генерацию ответа) являются синхронными - если они выполняют либо вычисление, либо ввод-вывод, они свяжут поток
ядро должно использовать межпоточные блокировки для защиты ключевых структур данных, поскольку многопоточность поддерживает так много этих синхронных запросов.

Вот почему на очень больших серверах обычно появляются серверы, такие как nginx (или Apache Traffic Server или любой современный коммерческий/высокопроизводительный прокси).

IMO Пули в вашем вопросе немного не соответствуют значению, SSL и deflate на самом деле не способствуют различиям здесь, поскольку они оба являются фильтрами, которые действительно не способствуют проблемам с масштабируемостью или даже связывают httpd с его традиционным API гарантии о жизненном цикле запроса или соединения. Фильтры, подобные этим (против обработчиков или основного фильтра, ответственного за низкоуровневый ввод-вывод), вероятно, являются наименее связанными с моделью обработки.

Но я также не думаю, что он так плохо сравнивается по сравнению со всеми, кроме самых экстремальных рабочих нагрузок или крайне ограниченных систем. Большинство тестов, которые я видел, имеют крайне низкое качество по той или иной причине.

Я думаю, что в основном люди хотят, чтобы веб-сервер сегодня называл себя прокси-сервером для более сложного сервера приложений (Java EE, PHP и т.д.), а сервер, предназначенный для эффективного ввода операций ввода-вывода без багажа API имеют ребро.