>> 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 пользователь Валентин Бартенев <vb...@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
