Отказ от apache в связке nginx + httpd + php?

Question

[Hint]

Как сейчас правильно подключать php к nginx? Какой способ является актуальным на данный момент? PHP 5.3.17.

Есть ли минусы в отказе от httpd (rewrite не используется)?

Answer 1

[ТыжСисАдмин]

php-fpm

Answer 2

[hell]

Боюсь, что огребу за свой совет кучу минусов, но тем не менее:

Месяца три назад, я 2 недели посвятил тестам — что лучше. Правда — у меня стоял PHP 5.4, nginx 1.2 и все это на Debian
Тестировал (и, разумеется, в процессе тестов тюнил ОС и все прочие настройки) четыре варианта — nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP (в последнем случае есть внешний нгинкс, работающий со статикой и отправляющий запросы к PHP на внутренний нгинкс) и nginx+apache+PHP-FPM.

Внутренние нгинкс и апач запускаются в режиме keepAlive off
У апача отрублено все лишнее (в моем случае оставлены dir, auth, mime, rpaf). ,haccess не используется (если че-то нужно органичить — ставим напрямую в конфигах сайта, все перенаправления — через внешний нгинкс)
У внешнего нгинкса включен gzip, отключено кеширование
Внутренние сервера логируют только ошибки php

Во всех случаях на реальные сайты натравливался siege с увеличенным таймаутом и с 1000 конкурентных запросов.

Да — и машинка — Хетзнеровская с 24 GB памяти.

Результаты получились следующие:

nginx + php — не котируется вообще. выводит память в свап, нагрузка в top — 140 — 150 примерно через минуту после начала осады. Манипуляции с системой и настройками не помогли.

nginx+apache+php-fpm — жрет память и залезает в свап, процессор особо не грузит. Есть проблемы со стабильностью (siege стабильно отрабатывал с параметром не более -c 500)

nginx+apache+php и nginx+nginx+php — примерно одинаковые результаты — средняя нагрузка в top — 3, среднее потребление памяти — 14 — 16 Gb. Количество транзакций также примерно одинаково (apache показывал результаты примерно на 3-4 транзакции в секунду лучше)

nginx+nginx+php работал чуть менее стабильно, чем nginx+apache+php (не чуть, даже — чуть-чуть — то есть пару тройку раз сокет все-таки падал, а в случае apache тaкого не было)

Пришлось остановиться на классике (хотя очень хотелось ограничиться nginxом)

Впрочем — это все — лирика. Я бы рекомендовал провести серию тестов с вашим софтом (и с вашим админом) — возможно вы получите другие результаты. Впрочем — и это почти наверняка — вариант с реверс-прокси будет заведомо более производительным.

Comments

[mgyk]

Покажите какой был конфиг php-fpm в ваших тестах, у меня все совсем было противоположное, работало около 50 вокреров на 8 GB RAM. php-fpm через socket, mysql тоже

[Борис Сёмов]

Не зря боитесь — о настройках ни слова…
nginx+nginx+php??? Какой смысл такого бреда? Такое нужно для балансирования нагрузки при нескольких бекэндах разве что. Nginx и так отдаст статику, не обращаясь к php.
Если у вас при этом nginx + php работает хуже, то у вас большие проблемы с настройками.

Answer 3

[la0]

Минусов особых нет (апач это очень функциональный «энтерпрайзный» реактор, для большинства проектов он избыточен).
см. php.net/manual/ru/install.fpm.php

Чтобы нормально без костылей писать конфиги nginx, нужно немного с ним поработать. (переводить продакшн раньше, чем тестовую/dev площадку уж точно не стоит).

Бытовая очевидность: если проблемы не в апаче, а в голове^W кривом коде, никакая смена вебсервера их не решит.

Comments

[ТыжСисАдмин]

Основная проблема в конфиге nginx это url-rewrite. А так всё понятно и вполне доступно.

[Иван Климчук]

хм, мне показалось, что там с эти как раз таки все проще и логичнее, чем в том же апаче. Плюс апача разве что в .htaccess для каждого хоста.

[ТыжСисАдмин]

.htaccess это огромный плюс, особенно если хостинг — клиент сам рулит многими функциями.
Насчёт реврайта, мне сложно было перейти, точнее не привычно и нужно думать было а не с закрытыми глазами писать)

Answer 4

[Renat Ibragimov]

NGINX + PHP-FPM очень стабильно работает уже более 2-х лет у меня, раньше подключал на порт, например :9000, сейчас удобнее подключать через socket'ы

Comments

[Иван Климчук]

так же перешел на сокеты. для каждого сайта свой конфиг и свой файл сокета, изоляция через системных пользователей.

[EugeneOZ]

hell,

Внутренние нгинкс и апач запускаются в режиме keepAlive off

этим вы создаёте много проблем посетителям. все картинки грузятся по очереди, все запросы по очереди…
ну и API, видимо, ваш проект не имеет, если вы позволяете себе такое.

ну и ппц глупо ваше сравнение выглядит без nginx+php-fpm и без цифр. «я где-то что-то тестировал, были какие-то результаты»… в таких случаях лучше вообще не говорить ничего.

[hell]

чего-йто вы недоразобрались, как работает reverse-proxy.
Всю статику (картинки файлы и т.д.) отдает внешний нгинкс, у которого, разумеется, кипэлайв не нулевой. запросы к движку этот внешний нигнкс проксирует внутрь (а в идеале некоторые еще и кеширует — но в данном случае мне было интересно «чистое» его поведение), он же отвечает за всевозможные рерайты урлов и переадресации. Посему ничего «по очереди» не получается.
Проект — это в данном случае около 100 сайтов с разной степенью нагрузки (от 10 до 10000 пользователей в сутки), с разной степенью функицонала (от почти статических страниц до полноценных web-приложений с кучей аякса)

«Ппц глупо» оно бы выглядело без nginx+php-fpm, если бы nginx+php-fpm не шел бы самым первым пунктом. То есть (это уже вспоминая далекий 2005 год, когда мы начали реверс-прокси использовать) — nginx+php-fpm, разумеется, быстрее apache+mod_php, особенно если апач со всеми приблудами, и nginx+php-fpm по крайне мере не особо проигрывает в скорости связке nginx+apache c приблудами + mod_php, но со свзяками nginx+nginx+php и nginx+apache (очищеный от безобразий с поиском .htaccess в каждой директории) +php оно никакого сравнения по производительности не выдерживает. О чем я, собственно и написал.
И, да — API в самом деле нету.

Answer 5

[transpond]

Минусов в отказе от httpd не вижу, однако, сколько людей, столько и мнений.
Меня данная связка пока не подводила.
Совет — смело устанавливай и пользуйся. Об установке неплохо написано здесь: habrahabr.ru/post/164401/