>> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
скореепо вине сложности правильной настройки последнего под данный
микробенчмарк.
Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
И выигрывают они не по вине сложности правильной настройки, а потому что
mod_php встраивается в апаче, но вся функциональность apache которая
обслуживает весь концерт никуда не девается, а она медленная.

>> fastCGI даже теоретически не может обогнать встроенное решение просто
потому, что нужны накладные расходы на пересылку данных.
Теоретически не знаю, а на практике обгоняет. По крайней мере на мультиюзер
окружениях и это тоже понятно: ведь apache надо переключать контекст между
раными userid, а fastCGI запускается отдельно для каждого юзвера.


>>В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг
для него, отдельно настраивать php-fpm, соответственно конфиг для него.
Ну а тут надо будет настраивать Unit и конфиг для него, и от конфига php вы
никуда не денетесь, потому как там тоже надо крутить. Без разницы в общем.

>> Для разных пользователей используется один и тот же модуль.
А кто переключает контект userid? Если Unit то на это будут уходить
доп.ресурсы как у apache

>> Насколько я знаю, перезагрузить добавить новый пул или удалить
существующий, без затрагивания процессов, принадлежащих к другим пулам, в
php-fpm невозможно.
Да. Но там где юзер=инстанс, мы можем обойтись перезапуском инстанса юзверя

>> Верно, об этих приседаниях и идет речь. И вам нужно об этом
позаботиться, продумать и спланировать весь процесс и нигде не ошибиться.
Для этого и придумали chef, ansible и прочее. Чтобы один раз оттестровать и
не ошибиться.

Дискуссию можно сворачивать, ибо спорить можно долго и наверное
безрезультатно. Тем более пока Unit ещё ранняя бета. Поживём-посмотрим как
будет дальше.

20 октября 2017 г., 18:56 пользователь Валентин Бартенев <vbart@nginx.com>
написал:

> On Friday 20 October 2017 18:21:35 Виктор Вислобоков wrote:
> >> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
> >> счет своей архитектуры.
> > Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php,
> так
> > что не вижу за счёт чего.
> > Хочу увидеть сравнительные тесты.
>
> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но скорее
> по вине сложности правильной настройки последнего под данный микробенчмарк.
>
> fastCGI даже теоретически не может обогнать встроенное решение просто
> потому,
> что нужны накладные расходы на пересылку данных.
>
>
> >
> >> Меньше движущихся частей. Unit требует меньше настройки и приседаний,
> >> чем связка nginx+php-fpm
> > Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и
> php-fpm
> > из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги
> для
> > разных версий PHP всё равно будут разными.
>
> В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг для
> него, отдельно настраивать php-fpm, соответственно конфиг для него.
>
> Вам не нужно собирать модули для Unit-а, если вы не собираетесь собирать
> собственных версий php. Вы также их ставите из дистрибутива.
>
> # apt-get install unit-php unit-python2.7 unit-python3.5 unit-go
>
> И они обновляются вместе с обновлением php/python в дистрибутиве.
>
>
> >
> >> Если вам требуется запускать на php-fpm несколько приложений от разных
> >> пользователей, то вам либо приходится использовать его pool-ы, либо
> >> запускать отдельные независимые инстансы php-fpm.
> >
> > Верно, так и тут придётся дополнительный модуль к Unit собирать и
> > подгружать.
>
> 1. Для разных пользователей используется один и тот же модуль.
>
> 2. Unit сам подгружает модули самостоятельно, для это не нужно ничего
> делать.
>
> 3. Собирать свой модуль нужно только в случаях, когда вы сами собираете
> свой php.
>
> 4. Не забывайте, что отдельный инстанс php-fpm - это ещё отдельный
> слушающий
> сокет и отдельная настройка в nginx под него.
>
>
> >
> >> В первом случае при добавлении, удалении, изменении
> >> пользователя/приложения приходится перезапускать весь рой процессов,
> даже
> >> если остальная конфигурация не претерпела изменений. Это может быть
> очень
> >> накладно по ресурсам.
> >
> > Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
> > php-fpm тоже поддерживает reload хотя и не такой гладкий, да и
> > перезапускать нужно будет только один нужный php-fpm
>
> Насколько я знаю, перезагрузить добавить новый пул или удалить
> существующий,
> без затрагивания процессов, принадлежащих к другим пулам, в php-fpm
> невозможно.
>
> У некоторых бывает до 10000 пулов и бывает так, что их нужно добавлять и
> менять
> по нескольку раз в минуту.
>
> >
> >> Во втором случае, управлять этим всем добром гораздо сложнее. Unit не
> >> требует отдельного менеджмента, в отличии от нескольких независимых
> php-fpm;
> >
> > Пока я этого не увидел. Скорее наоборот - на каждую версию php-fpm нужен
> > отдельный менеджмент Unit'а чтобы поключить соответствующий модуль.
> >
>
> 1. Повторюсь. Модули ставятся из пакетов, также как вы ставите сам php
> или python.
>
> 2. Unit-модуль, в отличии от отдельной программы, не добавляет
> дополнительных
> трудозатрат на его настройку, мониторинг и запуск.
>
> $ cat unit.log
> [..]
> 2017/10/19 17:47:42 [info] 16123#16123 discovery started
> 2017/10/19 17:47:42 [notice] 16123#16123 module: php 5.6.31-pl0-gentoo
> "build/php56.unit.so"
> 2017/10/19 17:47:42 [notice] 16123#16123 module: php 7.0.24 "build/
> php70.unit.so"
> 2017/10/19 17:47:42 [notice] 16123#16123 module: php 7.1.10 "build/
> php71.unit.so"
> 2017/10/19 17:47:42 [notice] 16123#16123 module: python 2.7.10 "build/
> py27.unit.so"
> 2017/10/19 17:47:42 [notice] 16123#16123 module: python 3.3.5 "build/
> py33.unit.so"
> 2017/10/19 17:47:42 [notice] 16123#16123 module: python 3.4.5 "build/
> py34.unit.so"
> [..]
>
> Выше в логе видно, что Unit запустил отдельный процесс discovery и узнал о
> доступных
> к использованию модулях и версиях в данный момент времени на моей системе.
>
>
> >> И во всех случаях требуются дополнительные приседания, чтобы обновить
> >> сам php или настройки приложения без потери запросов и просадки
> >> производительности.
> >
> > Если речь идёт о настолько критичных делах, то будет несколько апстримов,
> > которые можно обновлять по одному без обозначенных потерь.
> >
>
> Верно, об этих приседаниях и идет речь. И вам нужно об этом позаботиться,
> продумать и спланировать весь процесс и нигде не ошибиться.
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru