<div dir="ltr"><div><div><div>>> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но скореепо вине сложности правильной настройки последнего под данный микробенчмарк.<br></div>Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.<br></div>И выигрывают они не по вине сложности правильной настройки, а потому что mod_php встраивается в апаче, но вся функциональность apache которая обслуживает весь концерт никуда не девается, а она медленная.<br><br>>> fastCGI даже теоретически не может обогнать встроенное решение просто потому, что нужны накладные расходы на пересылку данных.<br></div>Теоретически не знаю, а на практике обгоняет. По крайней мере на мультиюзер окружениях и это тоже понятно: ведь apache надо переключать контекст между раными userid, а fastCGI запускается отдельно для каждого юзвера.<br><br><br><div>>>В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг для него, отдельно настраивать php-fpm, соответственно конфиг для него.<br></div><div>Ну а тут надо будет настраивать Unit и конфиг для него, и от конфига php вы никуда не денетесь, потому как там тоже надо крутить. Без разницы в общем.<br><br></div><div>>> Для разных пользователей используется один и тот же модуль.<br></div><div>А кто переключает контект userid? Если Unit то на это будут уходить доп.ресурсы как у apache<br><br>>> Насколько я знаю, перезагрузить добавить новый пул или удалить существующий, без затрагивания процессов, принадлежащих к другим пулам, в php-fpm невозможно.<br></div><div>Да. Но там где юзер=инстанс, мы можем обойтись перезапуском инстанса юзверя<br><br>>> Верно, об этих приседаниях и идет речь.  И вам нужно об этом позаботиться, продумать и спланировать весь процесс и нигде не ошибиться.<br></div><div>Для этого и придумали chef, ansible и прочее. Чтобы один раз оттестровать и не ошибиться.<br><br></div><div>Дискуссию можно сворачивать, ибо спорить можно долго и наверное безрезультатно. Тем более пока Unit ещё ранняя бета. Поживём-посмотрим как будет дальше.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">20 октября 2017 г., 18:56 пользователь Валентин Бартенев <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday 20 October 2017 18:21:35 Виктор Вислобоков wrote:<br>
>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за<br>
>> счет своей архитектуры.<br>
> Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так<br>
> что не вижу за счёт чего.<br>
> Хочу увидеть сравнительные тесты.<br>
<br>
</span>nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но скорее<br>
по вине сложности правильной настройки последнего под данный микробенчмарк.<br>
<br>
fastCGI даже теоретически не может обогнать встроенное решение просто потому,<br>
что нужны накладные расходы на пересылку данных.<br>
<span class=""><br>
<br>
><br>
>> Меньше движущихся частей.  Unit требует меньше настройки и приседаний,<br>
>> чем связка nginx+php-fpm<br>
> Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и php-fpm<br>
> из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги для<br>
> разных версий PHP всё равно будут разными.<br>
<br>
</span>В связке nginx+php-fpm как минимум нужно настраивать сам nginx и конфиг для<br>
него, отдельно настраивать php-fpm, соответственно конфиг для него.<br>
<br>
Вам не нужно собирать модули для Unit-а, если вы не собираетесь собирать<br>
собственных версий php.  Вы также их ставите из дистрибутива.<br>
<br>
# apt-get install unit-php unit-python2.7 unit-python3.5 unit-go<br>
<br>
И они обновляются вместе с обновлением php/python в дистрибутиве.<br>
<span class=""><br>
<br>
><br>
>> Если вам требуется запускать на php-fpm несколько приложений от разных<br>
>> пользователей, то вам либо приходится использовать его pool-ы, либо<br>
>> запускать отдельные независимые инстансы php-fpm.<br>
><br>
> Верно, так и тут придётся дополнительный модуль к Unit собирать и<br>
> подгружать.<br>
<br>
</span> 1. Для разных пользователей используется один и тот же модуль.<br>
<br>
 2. Unit сам подгружает модули самостоятельно, для это не нужно ничего делать.<br>
<br>
 3. Собирать свой модуль нужно только в случаях, когда вы сами собираете<br>
    свой php.<br>
<br>
 4. Не забывайте, что отдельный инстанс php-fpm - это ещё отдельный слушающий<br>
    сокет и отдельная настройка в nginx под него.<br>
<span class=""><br>
<br>
><br>
>> В первом случае при добавлении, удалении, изменении<br>
>> пользователя/приложения приходится перезапускать весь рой процессов, даже<br>
>> если остальная конфигурация не претерпела изменений.  Это может быть очень<br>
>> накладно по ресурсам.<br>
><br>
> Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.<br>
> php-fpm тоже поддерживает reload хотя и не такой гладкий, да и<br>
> перезапускать нужно будет только один нужный php-fpm<br>
<br>
</span>Насколько я знаю, перезагрузить добавить новый пул или удалить существующий,<br>
без затрагивания процессов, принадлежащих к другим пулам, в php-fpm невозможно.<br>
<br>
У некоторых бывает до 10000 пулов и бывает так, что их нужно добавлять и менять<br>
по нескольку раз в минуту.<br>
<span class=""><br>
><br>
>> Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не<br>
>> требует отдельного менеджмента, в отличии от нескольких независимых php-fpm;<br>
><br>
> Пока я этого не увидел. Скорее наоборот - на каждую версию php-fpm нужен<br>
> отдельный менеджмент Unit'а чтобы поключить соответствующий модуль.<br>
><br>
<br>
</span> 1. Повторюсь.  Модули ставятся из пакетов, также как вы ставите сам php или python.<br>
<br>
 2. Unit-модуль, в отличии от отдельной программы, не добавляет дополнительных<br>
    трудозатрат на его настройку, мониторинг и запуск.<br>
<br>
$ cat unit.log<br>
[..]<br>
2017/10/19 17:47:42 [info] 16123#16123 discovery started<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: php 5.6.31-pl0-gentoo "build/<a href="http://php56.unit.so" rel="noreferrer" target="_blank">php56.unit.so</a>"<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: php 7.0.24 "build/<a href="http://php70.unit.so" rel="noreferrer" target="_blank">php70.unit.so</a>"<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: php 7.1.10 "build/<a href="http://php71.unit.so" rel="noreferrer" target="_blank">php71.unit.so</a>"<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: python 2.7.10 "build/<a href="http://py27.unit.so" rel="noreferrer" target="_blank">py27.unit.so</a>"<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: python 3.3.5 "build/<a href="http://py33.unit.so" rel="noreferrer" target="_blank">py33.unit.so</a>"<br>
2017/10/19 17:47:42 [notice] 16123#16123 module: python 3.4.5 "build/<a href="http://py34.unit.so" rel="noreferrer" target="_blank">py34.unit.so</a>"<br>
[..]<br>
<br>
Выше в логе видно, что Unit запустил отдельный процесс discovery и узнал о доступных<br>
к использованию модулях и версиях в данный момент времени на моей системе.<br>
<span class=""><br>
<br>
>> И во всех случаях требуются дополнительные приседания, чтобы обновить<br>
>> сам php или настройки приложения без потери запросов и просадки<br>
>> производительности.<br>
><br>
> Если речь идёт о настолько критичных делах, то будет несколько апстримов,<br>
> которые можно обновлять по одному без обозначенных потерь.<br>
><br>
<br>
</span>Верно, об этих приседаниях и идет речь.  И вам нужно об этом позаботиться,<br>
продумать и спланировать весь процесс и нигде не ошибиться.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Валентин Бартенев<br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div>