Что установить: Apache Worker или Prefork? Каковы (не) преимущества каждого?

55

Судя по описаниям для Prefork и Worker MPM, кажется, что тип prefork несколько устарел, но я не могу найти правильное сравнение этих двух типов.

Что я хотел бы знать:

Каковы различия между двумя версиями?
Каковы (не) преимущества каждого типа сервера?
Существуют ли какие-либо основные рекомендации по выбору типа в зависимости от условий?
Есть ли большие различия в производительности между ними?

apache-2.2 mpm-worker mpm-prefork

— Арон Роттвил
источник

2

См. Как выбрать Apache MPM для использования?

— Янус Троелсен

40

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

— romble
источник

3

Я бы порекомендовал рабочий MPM, если вы не используете PHP. Worker - рекомендуемый MPM от Apache, он обеспечивает лучшую производительность и снижает накладные расходы. Только для того, чтобы PHP-разработчик никогда не слышал о безопасности потоков, нужно использовать prefork.

— Дэвид Пашли

16

PHP был потокобезопасным в течение очень долгого времени. Они только предлагают использовать pre-forkers, поскольку они не могут контролировать то, что делают другие библиотеки. Перестаньте обвинять PHP в бездействии других разработчиков.

— Алистер Булман

3

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

— Александар Иванишевич

5

По крайней мере, переменная ENV, изменяющая функцию, не будет поточно- ориентированной, например , setlocal php.net/manual/en/function.setlocale.php .

— радиус

4

Одно замечание: эти проблемы не применяются, если PHP подключен, например, с php-fpmпомощью FastCGI. Тогда с рабочим MPM все в порядке - тогда fpm будет запускать каждый PHP-запрос в своем собственном процессе, в то время как Apache может работать с многопоточностью. Проблема безопасности PHP-Thread только мешает вам использовать mod_php, который запускает PHP внутри процесса Apache.

— mschuett

13

Классическое решение для запуска небезопасных расширений при обслуживании большого количества (> 100) одновременных подключений состоит в том, чтобы запустить PHP на fastCGI (mod_fcgid, собственный модуль apache) и прокси-динамические запросы на него от экземпляра apache, который запускает Worker MPM.

Это позволит вам масштабировать от нескольких сотен до> 1000 одновременных подключений со скромным объемом памяти (4 ~ 8 ГБ) при обслуживании смеси статического и динамического содержимого.

Конечно, вы должны также исследовать интерфейсные решения для кэширования как часть вашего общего развертывания (memcached, лак).

Альтернативно, обновите до apache 2.4 и его собственного события MPM, которое обрабатывает параллелизм намного улучшенным способом (потоки запускаются при соединении, не ожидая опроса.)

— adaptr
источник

Не могли бы вы расширить комментарий к событию mpm? Как это складывается с MPM-работником?

— Sirex

В то время как рабочий MPM уже был основан на потоках и, следовательно, намного быстрее запускается и легче запускается, событие MPM больше не опрашивает сокет - оно получает уведомление об активности; следовательно, «событие».

— Адаптер

так что должно работать лучше на сайтах с высоким трафиком (13k / sec)?

— Sirex

6

Прошло около 3 лет с тех пор, как вопрос был опубликован, но я бы порекомендовал вам использовать рабочий MPM вместо предварительной форка, даже если вы используете PHP, чтобы получить лучшую производительность.

Что касается различий, предварительный форк не является многопоточным, поэтому сервер разветвляет процесс для каждого клиентского запроса (он предварительно разветвляется в ожидании новых запросов, так что разветвление не влияет на время ответа). Так как запросы являются сервером в отдельном процессе, это обычно увеличивает нагрузку на вашу память и процессор. Рабочий приносит многопоточность, которая легче и лучше использует память.

— aleemb
источник

2

Это что-то особенное в том, что вы служите. Если вы делаете много небольших статических соединений, потоки будут легче и быстрее. Если у вас есть только несколько больших приложений, постоянно появляющихся, у prefork может быть преимущество из-за зрелости и стабильности. Почему бы просто не настроить то, что вам нужно, протестировать один, заменить модуль MPM, попробовать еще раз, посмотреть, какой из них подходит вам лучше?

— Marcin
источник

Вы не можете произвольно «поменять» MPM в apache 2.2; он устанавливается во время компиляции.

— Адаптер

Вы можете с apt или RPM. В Debian есть несколько разных пакетов Apache 2, в зависимости от того, какой стиль вы предпочитаете.

— Брендан Берд

1

это зависит от типа и типа трафика, который вы будете иметь. А также, прежде всего, необходимо понять основное различие между префорком и рабочим. Надеюсь, что статья ниже поможет вам разобраться! http://slashroot.in/how-is-nginx-different-from-apache

— Сарат
источник

2

Мы предпочитаем, чтобы ответы содержали контент, а не ссылки на контент. Если бы вы могли предоставить краткое изложение того, что находится на цели ссылки, это наилучшая практика. Ссылка-гниль бывает.

— sysadmin1138

1

Вопрос был об Apache (nginx не apache) и об относительных достоинствах prefork или потоков (nginx не использует ни того, ни другого)

— symcbean