<div dir="ltr"><div><div><div><div><div><div>>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за счет своей архитектуры.<br></div>Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так что не вижу за счёт чего.<br></div>Хочу увидеть сравнительные тесты.<br><br>>> Меньше движущихся частей.  Unit требует меньше настройки и приседаний, чем связка nginx+php-fpm<br></div>Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и php-fpm из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги для разных версий PHP всё равно будут разными.<br><br>>> Если вам требуется запускать на php-fpm несколько приложений от разных пользователей, то вам либо приходится использовать его pool-ы, либо запускать отдельные независимые инстансы php-fpm.<br></div>Верно, так и тут придётся дополнительный модуль к Unit собирать и подгружать.<br><br>>> В первом случае при добавлении, удалении, изменении пользователя/приложения приходится перезапускать весь рой процессов, даже если остальная конфигурация не претерпела изменений.  Это может быть очень накладно по ресурсам.<br></div>Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно. php-fpm тоже поддерживает reload хотя и не такой гладкий, да и перезапускать нужно будет только один нужный php-fpm<br><br>>> Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не требует отдельного менеджмента, в отличии от нескольких независимых php-fpm;<br></div>Пока я этого не увидел. Скорее наоборот - на каждую версию php-fpm нужен отдельный менеджмент Unit'а чтобы поключить соответствующий модуль.<br><br><div><div>
<div>>> И во всех случаях требуются дополнительные приседания, чтобы обновить сам php или настройки приложения без потери запросов и просадки производительности.<br></div><div>Если речь идёт о настолько критичных делах, то будет несколько апстримов, которые можно обновлять по одному без обозначенных потерь.<br><br>>> Если завтра вам понадобится запустить ещё что-то на python, go, ruby, your language, у вас будет для этого уже знакомый и понятный инструмент.<br></div><div>Вот! Наконец-то вижу сильный аргумент! Согласен. Но пока нам нужен только PHP, это неважно.<br><br></div><div><div><div>>> Количество выполняемых функций будет расширяться, так что в дальнейшем Unit сможет стать не только легковесной заменой для php-fpm, но и ряда других компонентов, которые сейчас приходится использовать и настраивать в довесок.<br></div><div>Поживём-увидим! Пока что я каких-то очевидных преимуществ, ради которых бы стоило переходить на Unit не увидел.<br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">20 октября 2017 г., 18:05 пользователь Валентин Бартенев <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 17:27:30 Виктор Вислобоков wrote:<br>
> >> Каждое приложение со своей конфигурацией полностью изолировано.  Точно<br>
> также, как были бы изолированы отдельные процессы php-fpm, запущенные<br>
> независимо друг от друга на одной машине.<br>
><br>
> Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой<br>
> nginx+php-fpm.<br>
><br>
</span>[..]<br>
<br>
В произвольном порядке:<br>
<br>
 - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за<br>
   счет своей архитектуры.<br>
<br>
 - Меньше движущихся частей.  Unit требует меньше настройки и приседаний, чем<br>
   связка nginx+php-fpm.  Просто потому, что вместо нескольких компонентов<br>
   с разными подходами к конфигурации, которые нужно связывать друг с другом<br>
   и как-то затем мониторить, обновлять - получается один.<br>
<br>
 - Если вам требуется запускать на php-fpm несколько приложений от разных<br>
   пользователей, то вам либо приходится использовать его pool-ы, либо<br>
   запускать отдельные независимые инстансы php-fpm.<br>
<br>
   В первом случае при добавлении, удалении, изменении пользователя/приложения<br>
   приходится перезапускать весь рой процессов, даже если остальная конфигурация<br>
   не претерпела изменений.  Это может быть очень накладно по ресурсам.<br>
<br>
   Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не требует<br>
   отдельного менеджмента, в отличии от нескольких независимых php-fpm;<br>
<br>
   И во всех случаях требуются дополнительные приседания, чтобы обновить сам php<br>
   или настройки приложения без потери запросов и просадки производительности.<br>
<br>
 - Если завтра вам понадобится запустить ещё что-то на python, go, ruby, your<br>
   language, у вас будет для этого уже знакомый и понятный инструмент.<br>
<br>
 - Количество выполняемых функций будет расширяться, так что в дальнейшем Unit<br>
   сможет стать не только легковесной заменой для php-fpm, но и ряда других<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>