Предполагается, что Nginx + php-fpm будет намного быстрее, чем Apache + mod-php

Ответ 1

Я немного поработал над этим и обнаружил, что Nginx будет хорошо работать со статическими ресурсами, а не с другой доставкой динамического контента, такой как обработка php, которая должна быть выполнена с помощью внешнего приложения, такого как php-fpm. Поэтому, если ваше веб-приложение имеет узкое место производительности при обработке php, то замена Apache на Nginx не будет решением.

В следующей статье объясняется подробное исследование, связанное с сравнением статической доставки конкурирующих и php script с использованием Apache + mod_php и Nginx + php-fpm.

http://blog.a2o.si/2009/06/24/apache-mod_php-compared-to-nginx-php-fpm/

Ниже приведены выводы, описанные в этой статье.

Заключение или "следует переключиться с Apache на Nginx?"

• Короткий ответ: я не знаю.

• Более длинные ответы здесь:

  • Если у вас много сайтов, а пользователи используют файлы .htaccess и часто меняют их, то ответ, вероятно, "нет". Стоимость перехода на Nginx и конвертация всей конфигурации в новый формат обычно достигает стоимости покупки другого сервера.
  • Если у вас есть одно приложение на нескольких серверах, и большая часть вычислительной мощности не потребляется службой статического содержимого файла, ответ также, вероятно, "нет".
  • Если вы в основном используете статический контент, ответ явно "да" .
  • Если вы создаете новую систему для решения для веб-хостинга, ответ, вероятно, "да" , при условии, что пользователи не пропустят функциональность .htaccess или будут предоставлены другими средствами.
  • Если вы объединяете службы с некоторыми технологиями виртуализации, тогда ответ, вероятно, "да" , так как Nginx имеет меньшую площадь памяти, чем Apache.
  • Если вы ищете Nginx в качестве оптимизации вашего PHP-сервера, посмотрите еще раз, но не на Nginx, на ваш код приложения.

Ответ 2

У меня есть веб-сайт с балансировкой нагрузки на 3 сервера. 2 из них работают на nginx с PHP-FPM (новые). Однако основной сервер находится на Apache + PHP FastCGI, что составляет примерно 40% трафика. Недавно я подумал об изменении Apache и nginx; поэтому я установил nginx на один и тот же сервер для другого IP-адреса и сделал несколько тестов. Но удивительно, что Apache может генерировать страницу в 10-20 миллисекунд при каждом ударе, но nginx занимает 60-70 миллисекунд. nginx быстрее для статических файлов, но если у вас есть CDN, нет необходимости беспокоиться о статическом контенте. Apache - отличный сервер. Но попробуйте FastCGI, а не модуль PHP.

Ответ 3

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

То, что быстрее, mod_php или ext-fpm, не было доказано, и оно может варьироваться. Что касается производительности, у вас есть три соображения: теория, реализация, сценарий использования, ресурсы и нагрузка.

Теоретически mod_php - самый быстрый из всех возможных. С mod_php веб-сервер и интерпретатор напрямую взаимодействуют, они совместно используют одни и те же ресурсы и пространство памяти. С ext-fpm у вас есть отдельные процессы, которые взаимодействуют не так напрямую и должны дублировать ресурсы.

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

В то время как ext-fpm, используя FastCGI, является попыткой привести модель отдельного процесса к максимальной теоретической скорости, максимальная теоретическая скорость все еще медленнее максимальной теоретической скорости унифицированных процессов.

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

Реализация mod_php не обязательно приводит к максимальной теоретической скорости. Эти два аспекта могут не так сильно отличаться друг от друга, как можно было бы ожидать, особенно потому, что довольно часто издержки SAPI могут оказаться тривиальными по сравнению со всем остальным, что происходит при обработке статического запроса. Многим тестам приходится тестировать практически с помощью noop-скриптов, чтобы разница была значительной.

Широко распространено мнение, что ext-fpm "быстр". Есть много сил, которые сохраняют это, некоторые из которых невинны, другие извлекают выгоду из некомпетентности, а некоторые из них не совсем правы.

1. Apache httpd не хочет рекомендовать использовать mod_php и не работает с многопоточными MPM по разным причинам. Apache httpd с многопоточными или управляемыми событиями моделями, которые могут иметь некоторые запросы, влияющие на производительность и не обслуживающие PHP. Хотя PHP добился значительного прогресса в поддержке как многопоточных, так и событийно-ориентированных моделей, он еще далек от событийно-ориентированной и его многопоточная поддержка не была столь же проверенной в бою, как это традиционно для поддержки процессов. Многие люди смущены этим. Это не то, что делает PHP быстрее. Это компромисс. Потенциально замедлить PHP, ускорить статический контент. Apache начал рекомендовать против mod_php полностью, что может запутать многих людей, а также вероятное происхождение ошибочного мнения, что ext-fpm "быстрее".
2. Воодушевленные такими вещами, как рекомендация Apache, многие люди пытались использовать ext-fpm, а затем использовали свои платформы, такие как выступления на конференциях или в блогах, чтобы сообщать о своих "успехах", которые затем распространяются на более широкую впечатлительную аудиторию.
3. Иногда, когда результаты лучше переключаются на ext-fpm, причина не в том, что люди ожидают. Многие люди при переключении с mod_php на ext-fpm делают больше, чем это или другие факторы.
4. В технологии слово "пост" особенно проблематично. Часто это ничего не значит. Несколько последних систем, которые я использовал как быстрые (очень популярные технологии), оказались противоположными. Многие люди ошибочно принимают за самый быстрый смысл. На самом деле это не имеет большого значения. Быстро с точки зрения восприятия? Жесткий диск, вращающийся со скоростью 100 об/мин, будет казаться "быстрым" для большинства людей. Кажется, что вращение жесткого диска со скоростью 1000 оборотов в минуту для большинства людей будет "быстрым". Быстрее не значит много.
5. Конфликт интересов. У nginx есть коммерческое предприятие, и еще неизвестно, может ли это быть источником некоторого маркетинга для ext-fpm. Он служит для пользователей nginx верой, что он быстрее, чем mod_php, который доступен только для конкурирующего веб-сервера. Однако для nginx и PHP доступен модуль потока, поэтому не похоже, что это будет вероятным источником лоббирования для ext-fpm. Главный результат в Google, однако, связан с маркетинговым блогом, пытающимся привлечь трафик к коммерческим хостинговым службам, который пропускает большинство важных деталей, так что есть партии, которые его доят.

Часто, когда люди видят другой результат, они не понимают, почему. Интимные детали их процесса, измерений и трафика не учитываются. Люди часто пытаются повторить эти успехи и терпят неудачу, оставляя бесконечные результаты поиска людей, спрашивающих, почему это не быстрее. Самое главное - люди находят успех, когда используют MPM с несколькими процессами с mod_php, но с большой нагрузкой статического контента. Эти случаи могут быть особенно обманчивы, поскольку нагрузка от статических запросов может отскочить назад на PHP.

Еще одна распространенная ошибка - люди также тестируют две разные конфигурации. Конфигурация для php-fpm может быть более оптимизированной, чем для mod_php. Иногда это может быть так просто, как люди оптимизируют все, что они ожидают, быстрее, пренебрегая оригиналом. Это особенно актуально, когда люди могут делать такие вещи, как не проверять, были ли запросы успешными, а также изменять такие вещи, как ограничение памяти или максимальное время выполнения. Многое может измениться в конфигурации, когда люди должны только изменить SAPI, иногда даже неизбежно, иногда даже прозрачно. Типичным примером может быть то, что ограничения на веб-сервер могут быть недостаточными для максимального использования ресурсов сервера, когда ext-fpm сможет порождать дополнительные процессы, чтобы использовать преимущества дополнительных ядер. Обычно люди перемещают такие вещи, как маршрутизация с PHP на веб-сервер для FPM.

По сравнению с mod_php с многопоточным однопоточным MPM, ext-fpm является хорошим конкурентом с множеством всесторонних преимуществ, хотя повышение производительности строго не гарантируется. Хотя, если ваша нагрузка полностью обслуживает запросы PHP, то Apache уже более менее делает то, что иначе делал бы ext-fpm.

Существует также несоответствие между такими вещами, как задержка и пропускная способность, и циклы, байты и ожидания.

Теоретически, путь вперед - это php-zts с помощью ngx_php или mod_php. Большое предостережение заключается в том, что php-zts не получил почти никакого внимания, заботы и внимания как php-nts, так что он вносит накладные расходы в само выполнение PHP, что в настоящее время очень затрудняет конкуренцию с php-fpm. Реализация не приводит к достижению оптимального уровня. В некоторых случаях субоптимум может быть преуменьшением. Многие люди обеспокоены надежностью многопоточного PHP, который может повлиять или не повлиять на вас. Это, конечно, не будет такой большой проблемой, если вы обслуживаете только динамический контент и не используете службу общего хостинга. Похоже, что это потенциально кампания страха, организованная Apache. Должно быть достаточно людей, использующих php-zts для платформ, где единственный вариант, чтобы он был относительно стабильным.

Есть и другие варианты, хотя их может быть больше. Можно даже открыть unix-сокет самостоятельно, проанализировать FCGI и обработать его асинхронно с такими вещами, как select. Предупреждение о событиях в PHP заключается в том, что большинство основных высокоуровневых библиотек ввода-вывода, таких как MySQL, не поддерживают его унифицированно.

php-swoole начинает выглядеть многообещающе, хотя это еще рано. Ситуация с php-fpm, mod_php и php-zts беспорядочная.