Re: unit-0.2 beta release

2017-12-29 Пенетрантность Валентин Бартенев 
On Saturday, 16 December 2017 16:05:22 MSK Валентин Бартенев wrote:
> On Friday, 15 December 2017 21:53:57 MSK Иван wrote:
> > Прекрасная новость!
> > 
> > А пакеты для debian9? А когда планируется релиз?
> > 
> [..]
> 
> Пакеты для Debian надеюсь сделаем до конца года.
> Релиз запланирован на второй квартал 2018.
> 

Как и обещал, пакеты для Debian:
https://unit.nginx.org/installation/#debian-packages

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-12-16 Пенетрантность Валентин Бартенев 
On Friday, 15 December 2017 21:53:57 MSK Иван wrote:
> Прекрасная новость!
> 
> А пакеты для debian9? А когда планируется релиз?
> 
[..]

Пакеты для Debian надеюсь сделаем до конца года.
Релиз запланирован на второй квартал 2018.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-12-15 Пенетрантность Иван 
Прекрасная новость!

А пакеты для debian9? А когда планируется релиз?

В письме от пятница, 15 декабря 2017 г. 20:37:37 MSK пользователь Валентин 
Бартенев написал:
> On Friday 15 December 2017 17:57:42 Иван wrote:
> [..]
> 
> > А интеграция ruby в ближних планах есть?
> 
> В первом квартале 2018 планируем сделать Ruby и Perl.
> 
> --
> Валентин Бартенев
> ___
> 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

Re: unit-0.2 beta release

2017-12-15 Пенетрантность Валентин Бартенев 
On Friday 15 December 2017 17:57:42 Иван wrote:
[..]
> 
> А интеграция ruby в ближних планах есть?
> 

В первом квартале 2018 планируем сделать Ruby и Perl.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-12-15 Пенетрантность Иван 
Здравствуйте!

В письме от пятница, 20 октября 2017 г. 22:58:00 MSK пользователь Igor Sysoev 
написал:

> 
> С точки зрения юнита, языки делятся на две категории:
> 1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют
> некий
 стандартный интерфейс для встраивания в веб-сервер;
> 2) встраивание модуля юнита в приложение: Go, Node.js, Java.
> 
> Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку
> его популярность падает.
> 


А интеграция ruby в ближних планах есть?

С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-26 Пенетрантность Алексей Сундуков 
20 октября 2017 г., 18:44 пользователь Slawa Olhovchenkov 
написал:
> тут проблема со стандартным путями получения pear/pecl слинкованными с
> разными версиями php. мне как-то не известны дистрибутивы,
> предоставляющие это из коробки.

Но всегда можно подключить альтернативные репозитории в духе
https://www.dotdeb.org/ или https://deb.sury.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-24 Пенетрантность Валентин Бартенев 
On Friday 20 October 2017 22:30:41 Vadim A. Misbakh-Soloviov wrote:
> >  - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
> >счет своей архитектуры.
> > 
> 
> Я что-то недопонял...
> 
> Данное утверждение предполагает использование Unit без NginX перед ним?..

Да.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-24 Пенетрантность Nick Shadrin 

> On Oct 20, 2017, at 08:30, Vadim A. Misbakh-Soloviov  wrote:
> 
>> - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>>   счет своей архитектуры.
>> 
> 
> Я что-то недопонял...
> 
> Данное утверждение предполагает использование Unit без NginX перед ним?..

Существуют разные архитектуры и задачи.
В отдельных случаях, в глубине сети, в бэкенде, это будет допустимо.

-- 
Nick Shadrin / Sr. Product Manager / n...@nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-24 Пенетрантность Nick Shadrin 
Да, unit будет оставаться доступным по лицензии Apache 2.0.
Все текущие функции будут оставаться открытыми.

-- 
Nick Shadrin / Sr. Product Manager / n...@nginx.com



> On Oct 24, 2017, at 01:49, Andrey Velikoredchanin  
> wrote:
> 
> Вопрос разработчикам nginx unit - его лицензия будет оставаться открытой в 
> будущем? Будет-ли версия Enterprise и чем она будет отличаться от открытой?
> ___
> 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

Re: unit-0.2 beta release

2017-10-24 Пенетрантность Andrey Velikoredchanin 
Вопрос разработчикам nginx unit - его лицензия будет оставаться открытой в
будущем? Будет-ли версия Enterprise и чем она будет отличаться от открытой?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-22 Пенетрантность Vadim A. Misbakh-Soloviov 
>  - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>счет своей архитектуры.
> 

Я что-то недопонял...

Данное утверждение предполагает использование Unit без NginX перед ним?..
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 10:41:41PM +0300, Виктор Вислобоков wrote:

> >> нет. на самом деле все сильно зависит от того, что происходит на каждый
> запрос внутри php. вполне возможно, что разницей между mod_php и php-fpm
> можно просто пренебречь.
> Простите, но я же не голословно говорю.
> Пытались мы, не один раз пытались, крутили все ручки, делали что только
> можно, но php-fpm делает apache+mod_php в разы.

ну пускай внутри php-fpm один запрос будет выполняться одну секунду.
по вашему он в mod_php будет выполняться секунды? извЕните, но это бред.

> Попробуйте сами, наберите одинаковую конфигуацию на один сайт с тем и этим
> и запустите нагрузочное тестирование

было бы желание, а результат можно получить любой напередзаданный:

а) одинаково
б) апач выигрывает
в) fpm выигрывает

правильный подбор сайта рулит.

> 20 октября 2017 г., 22:38 пользователь Slawa Olhovchenkov 
> написал:
> 
> > On Fri, Oct 20, 2017 at 07:19:59PM +0300, Виктор Вислобоков wrote:
> >
> > > >> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
> > > скореепо вине сложности правильной настройки последнего под данный
> > > микробенчмарк.
> > > Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
> > > nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
> > > И выигрывают они не по вине сложности правильной настройки, а потому что
> > > mod_php встраивается в апаче, но вся функциональность apache которая
> > > обслуживает весь концерт никуда не девается, а она медленная.
> >
> > нет. на самом деле все сильно зависит от того, что происходит на
> > каждый запрос внутри php. вполне возможно, что разницей между mod_php
> > и php-fpm можно просто пренебречь.
> >
> > ___
> > 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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Andrey Oktyabrskiy 

Igor Sysoev wrote:

С точки зрения юнита, языки делятся на две категории:
1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют некий
   стандартный интерфейс для встраивания в веб-сервер;
2) встраивание модуля юнита в приложение: Go, Node.js, Java.
Спасибо. Была бы очень кстати какая-то документашка для (1). Понимаю, 
что на данный момент это несколько преждевременно.



Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку
его популярность падает.

Ну меня больше что-то типа Lua интересует.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Igor Sysoev 
> On 20 Oct 2017, at 22:50, Andrey Oktyabrskiy  wrote:
> 
> Andrey Velikoredchanin wrote:
>> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват,
>> но на нем еще много чего написано и пишется.
> Я бы обобщил вопрос: насколько сложно пришить к юниту новый интерпретатор?

С точки зрения юнита, языки делятся на две категории:
1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют некий
   стандартный интерфейс для встраивания в веб-сервер;
2) встраивание модуля юнита в приложение: Go, Node.js, Java.

Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку
его популярность падает.


-- 
Igor Sysoev
http://nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Andrey Oktyabrskiy 

Andrey Velikoredchanin wrote:

Кстати, а для perl предвидится реализация модуля? Он, конечно, староват,
но на нем еще много чего написано и пишется.

Я бы обобщил вопрос: насколько сложно пришить к юниту новый интерпретатор?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> нет. на самом деле все сильно зависит от того, что происходит на каждый
запрос внутри php. вполне возможно, что разницей между mod_php и php-fpm
можно просто пренебречь.
Простите, но я же не голословно говорю.
Пытались мы, не один раз пытались, крутили все ручки, делали что только
можно, но php-fpm делает apache+mod_php в разы.
Попробуйте сами, наберите одинаковую конфигуацию на один сайт с тем и этим
и запустите нагрузочное тестирование

20 октября 2017 г., 22:38 пользователь Slawa Olhovchenkov 
написал:

> On Fri, Oct 20, 2017 at 07:19:59PM +0300, Виктор Вислобоков wrote:
>
> > >> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
> > скореепо вине сложности правильной настройки последнего под данный
> > микробенчмарк.
> > Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
> > nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
> > И выигрывают они не по вине сложности правильной настройки, а потому что
> > mod_php встраивается в апаче, но вся функциональность apache которая
> > обслуживает весь концерт никуда не девается, а она медленная.
>
> нет. на самом деле все сильно зависит от того, что происходит на
> каждый запрос внутри php. вполне возможно, что разницей между mod_php
> и php-fpm можно просто пренебречь.
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 07:19:59PM +0300, Виктор Вислобоков wrote:

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

нет. на самом деле все сильно зависит от того, что происходит на
каждый запрос внутри php. вполне возможно, что разницей между mod_php
и php-fpm можно просто пренебречь.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Igor Sysoev 
> On 20 Oct 2017, at 22:03, S.A.N  wrote:
> 
> Будет хорошо создать здесь отдельные maillist для Unit.

http://mailman.nginx.org/mailman/listinfo/unit
Но это только английский.


-- 
Igor Sysoev
http://nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность S.A.N 
Я уже подымал эту тему на Github
https://github.com/nginx/unit/issues/6

Будет хорошо создать здесь отдельные maillist для Unit.

Я согласен с теми кто считает что Unit сложно будет конкурировать с
PHP-FPM.

1. Простота в настройке и запуске разных версий РНР - это совсем не сложно,
есть пакеты Remi разных РНР версий, подключаешь их все как хочешь, проблем
нет, но с каждым годом потребности в РНР 5 будет все меньше, все переходят
на РНР 7+.

2. Производительность, пока что говорить рано, но уже понятно что для
статики и кеширование пока что нужен Nginx, значит Unit нужно проксировать,
это означает дополнительный сокет рассходы, Browse -> Nginx -> Unit это тоже
самое как сейчас Browse -> Nginx -> FPM, когда Unit научитися отдавать
статику и кешировать ответы тогда вопрос кто будет заниматься балансировкой,
сейчас это делается в Nginx указываются пулы upstream к удаленным FPM
бекендам, это значит что Unit тоже придется проксировать если нужна
балансировка нагрузки.


Но, я вижу свободную и перспективную нишу для Unit, дело в том что PHP-FPM
нужен только тем РНР скриптам которые "умирают" после каждого запроса. Мы
уже три года в продакшене используюм РНР скрипты которые запускаются через
PHP-cli с модулем libuv он нужен для evetloop и асинхрого I/O, на РНР
написан НТТР сервер который асинхорно обрабатывает все НТТР запросы от
Nginx. Это работает на 40% быстрей чем Node.js и 200% чем PHP-FPM и дает
много возможностей websocket и много другое.

Короче говоря в РНР нет промышленного App Server, как в Node.js, ваш Unit
отличный претендент на роль True App Server для PHP, то что сейчас в Unit
пулы отдельных РНР процессов которые очищают состояния скрипта после каждого
запроса, это не круто, и для этого уже есть хорошее решения - PHP-FPM.

Мне от Unit, нужны только три event в userland моего скрипта, причем очень
правильно если бы Unit умел не только НТТР но и Websocket, вот event которые
универсальны для НТТР и для Websocket, бекенд будет полностью абстрагирован
от протокола клиента.

onOpen - новое соединения
onMessage  - новое сообщения или новый запрос если это НТТР протокол
onError - ошибка.
onClose - коректное завершения соединения.

РНР скрипт не блокироваться и Unit может вызывать эти евенты не дожидаясь
ответа на предыдущий, это очень эффективно и быстро.
Если вам интересно я могу детально обсуждать.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276967,277004#msg-277004

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Pavel V. 
Здравствуйте, Andrey.

Вы писали 21 октября 2017 г., 0:33:01:

> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
> на нем еще много чего написано и пишется.

Было бы интересно.

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Andrey Velikoredchanin 
Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
на нем еще много чего написано и пишется.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> 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 пользователь Валентин Бартенев 
написал:

> 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
> невозможно.
>
> У некоторых бывает до 1 пулов и бывает так, что их нужно добавлять и
> менять
> по нескольку раз в минуту.
>
> >
> >> Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не
> >> требует отдельного менеджмента, в отличии от нескольких независимых
> php-fpm;
> >
> > Пока я этого не увидел. Скорее

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Валентин Бартенев 
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 невозможно.

У некоторых бывает до 1 пулов и бывает так, что их нужно добавлять и менять
по нескольку раз в минуту.

> 
>> Во втором случае, управлять этим всем добром гораздо сложнее.  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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
в минуту и соединениями, живущими сутками, из-за которых в памяти висят
тысячи воркеров.
Согласен, как и есть проекты, которые выносят функциональность nginx на
уровень ядра Linux :)
Специфика проектов бывает разная, кто бы спорил, но я скорее размышляю на
предмет массовости использования Unit.

20 октября 2017 г., 18:26 пользователь Igor Sysoev  написал:

> > On 20 Oct 2017, at 18:21, Виктор Вислобоков 
> wrote:
> >
> > Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
>
> В 2002 году я тоже так думал.
>
> А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
> в минуту и соединениями, живущими сутками, из-за которых в памяти висят
> тысячи воркеров.
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
счет своей архитектуры.
Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так
что не вижу за счёт чего.
Хочу увидеть сравнительные тесты.

>> Меньше движущихся частей.  Unit требует меньше настройки и приседаний,
чем связка nginx+php-fpm
Опять же спорно. Для nginx + php-fpm требует лишь nginx из дистра и php-fpm
из дистра, нет необходимости дособирать какие-то доп.модули. А конфиги для
разных версий PHP всё равно будут разными.

>> Если вам требуется запускать на php-fpm несколько приложений от разных
пользователей, то вам либо приходится использовать его pool-ы, либо
запускать отдельные независимые инстансы php-fpm.
Верно, так и тут придётся дополнительный модуль к Unit собирать и
подгружать.

>> В первом случае при добавлении, удалении, изменении
пользователя/приложения приходится перезапускать весь рой процессов, даже
если остальная конфигурация не претерпела изменений.  Это может быть очень
накладно по ресурсам.
Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
php-fpm тоже поддерживает reload хотя и не такой гладкий, да и
перезапускать нужно будет только один нужный php-fpm

>> Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не
требует отдельного менеджмента, в отличии от нескольких независимых php-fpm;
Пока я этого не увидел. Скорее наоборот - на каждую версию php-fpm нужен
отдельный менеджмент Unit'а чтобы поключить соответствующий модуль.

>> И во всех случаях требуются дополнительные приседания, чтобы обновить
сам php или настройки приложения без потери запросов и просадки
производительности.
Если речь идёт о настолько критичных делах, то будет несколько апстримов,
которые можно обновлять по одному без обозначенных потерь.

>> Если завтра вам понадобится запустить ещё что-то на python, go, ruby,
your language, у вас будет для этого уже знакомый и понятный инструмент.
Вот! Наконец-то вижу сильный аргумент! Согласен. Но пока нам нужен только
PHP, это неважно.

>> Количество выполняемых функций будет расширяться, так что в дальнейшем
Unit сможет стать не только легковесной заменой для php-fpm, но и ряда
других компонентов, которые сейчас приходится использовать и настраивать в
довесок.
Поживём-увидим! Пока что я каких-то очевидных преимуществ, ради которых бы
стоило переходить на Unit не увидел.


20 октября 2017 г., 18:05 пользователь Валентин Бартенев 
написал:

> On Friday 20 October 2017 17:27:30 Виктор Вислобоков wrote:
> > >> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> > также, как были бы изолированы отдельные процессы php-fpm, запущенные
> > независимо друг от друга на одной машине.
> >
> > Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой
> > nginx+php-fpm.
> >
> [..]
>
> В произвольном порядке:
>
>  - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>счет своей архитектуры.
>
>  - Меньше движущихся частей.  Unit требует меньше настройки и приседаний,
> чем
>связка nginx+php-fpm.  Просто потому, что вместо нескольких компонентов
>с разными подходами к конфигурации, которые нужно связывать друг с
> другом
>и как-то затем мониторить, обновлять - получается один.
>
>  - Если вам требуется запускать на php-fpm несколько приложений от разных
>пользователей, то вам либо приходится использовать его pool-ы, либо
>запускать отдельные независимые инстансы php-fpm.
>
>В первом случае при добавлении, удалении, изменении
> пользователя/приложения
>приходится перезапускать весь рой процессов, даже если остальная
> конфигурация
>не претерпела изменений.  Это может быть очень накладно по ресурсам.
>
>Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не
> требует
>отдельного менеджмента, в отличии от нескольких независимых php-fpm;
>
>И во всех случаях требуются дополнительные приседания, чтобы обновить
> сам php
>или настройки приложения без потери запросов и просадки
> производительности.
>
>  - Если завтра вам понадобится запустить ещё что-то на python, go, ruby,
> your
>language, у вас будет для этого уже знакомый и понятный инструмент.
>
>  - Количество выполняемых функций будет расширяться, так что в дальнейшем
> Unit
>сможет стать не только легковесной заменой для php-fpm, но и ряда других
>компонентов, которые сейчас приходится использовать и настраивать в
> довесок.
>
> --
> Валентин Бартенев
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Валентин Бартенев 
On Friday 20 October 2017 17:27:30 Виктор Вислобоков wrote:
> >> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> также, как были бы изолированы отдельные процессы php-fpm, запущенные
> независимо друг от друга на одной машине.
> 
> Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой
> nginx+php-fpm.
> 
[..]

В произвольном порядке:

 - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
   счет своей архитектуры.

 - Меньше движущихся частей.  Unit требует меньше настройки и приседаний, чем
   связка nginx+php-fpm.  Просто потому, что вместо нескольких компонентов
   с разными подходами к конфигурации, которые нужно связывать друг с другом
   и как-то затем мониторить, обновлять - получается один.

 - Если вам требуется запускать на php-fpm несколько приложений от разных
   пользователей, то вам либо приходится использовать его pool-ы, либо
   запускать отдельные независимые инстансы php-fpm.

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

   Во втором случае, управлять этим всем добром гораздо сложнее.  Unit не 
требует
   отдельного менеджмента, в отличии от нескольких независимых php-fpm;

   И во всех случаях требуются дополнительные приседания, чтобы обновить сам php
   или настройки приложения без потери запросов и просадки производительности.

 - Если завтра вам понадобится запустить ещё что-то на python, go, ruby, your
   language, у вас будет для этого уже знакомый и понятный инструмент.

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

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 05:29:15PM +0300, Igor Sysoev wrote:

> > On 20 Oct 2017, at 17:21, Slawa Olhovchenkov  wrote:
> > 
> > On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
> > 
>  Так в таком случае использование unit еще выгоднее: ему не надо держать
> >> master-процесс для каждой версии php, не говоря о процессе для каждого
> >> пользователя.
> >> Не представляю как это будет работать.
> >> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> >> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> >> случае не получится загрузить в один веб-сервер несколько версий этого
> >> модуля.
> > 
> > на самом деле загрузить-то получится (наверное, не проверял), а вот
> > активировать нужный для конкретно URL может быть проблемой.
> > 
> > впрочем, возможно проблему решит правка сырцов для замены директив
> > php_* на phpXY_*.
> > 
> > в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> > случае php (и я не смотрел как он решает проблему с собственно php
> > разных версий).
> 
> В unit главный процесс сначала форкается, а потом динамически подгружает
> нужный модуль, который слинкован с соответствующей версией php/python.
> Поэтому можно одновременно запускать разные версии языков.

тут проблема со стандартным путями получения pear/pecl слинкованными с
разными версиями php. мне как-то не известны дистрибутивы,
предоставляющие это из коробки.
да, есть способы, позволяющие этого добиться, скажем с FreeBSD ports,
но это не самоочевидно. для rpm/deb это, как я понимаю, еще менее
очевидно из-за малой популярности пересборки и меньшего понимания
процесса массами. я собственно об этом.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Igor Sysoev 
> On 20 Oct 2017, at 17:34, Виктор Вислобоков  wrote:
> 
> >> В unit главный процесс сначала форкается, а потом динамически подгружает 
> >> нужный модуль, который слинкован с соответствующей версией php/python.  
> >> Поэтому можно одновременно запускать разные версии языков.
> Эээ... не совсем понял.
> А вот этот "нужный модуль" это часть Unit? Если да, то каким образом 
> достигается его линковка например с разными версиями PHP одновременно? Или 
> это целый набор "нужных модулей" каждый под нужную нам версию PHP? Если да, 
> то получается мы должны собрать каждый такой "нужный модуль" для каждой 
> версии PHP которую планируем использовать?

Да:

./configure
./configure php --config=php53-config --module=php53
./configure php --config=php71-config --module=php71
make

В build будут собраны php53.unit.so и php71.unit.so.


-- 
Igor Sysoev
http://nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Илья Шипицин 
и вот, кажется, интересные штуки

# grep '(error' typescript
[src/go/unit/nxt_go_port_memory.c:52]: (error) Undefined behavior: Variable
'name' is used as parameter and destination in s[n]printf().
[src/nxt_lib.c:96]: (error) Uninitialized variable: n
[src/nxt_main_process.c:398]: (error) Memory pointed to by 'start' is freed
twice.
[src/nxt_php_sapi.c:313]: (error) Uninitialized struct member:
script_name.start
[src/nxt_port_memory.c:475]: (error) Dereferencing 'mmap_handler' after it
is deallocated / released


20 октября 2017 г., 19:30 пользователь Илья Шипицин 
написал:

> Валентин, посмотрите вот эти штуки ?
>
> # grep '(warning' typescript
> [src/nxt_file_cache.c:290] -> [src/nxt_file_cache.c:302]: (warning) Either
> the condition 'handler==NULL' is redundant or there is possible null
> pointer dereference: handler.
> [src/nxt_port_socket.c:498] -> [src/nxt_port_socket.c:505]: (warning)
> Either the condition 'b==NULL' is redundant or there is possible null
> pointer dereference: b.
>
>
> и, кажется, не работают тесты при "make tests" (вот это прямо
> напрашивается в travis)
>
> я хотел этим заняться, завал, к сожалению еще на пару месяцев
>
> 20 октября 2017 г., 19:25 пользователь Валентин Бартенев 
> написал:
>
> On Friday 20 October 2017 16:48:31 Slawa Olhovchenkov wrote:
>> > On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
>> >
>> > > Так в таком случае использование unit еще выгоднее: ему не надо
>> держать
>> > > master-процесс для каждой версии php, не говоря о процессе для каждого
>> > > пользователя.
>> > >
>> > > P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем
>> под
>> > > каждого пользователя запускать отдельный master-процесс? Достаточно
>> ведь
>> > > завести для конкретного пользователя свой pool (работающий от имени
>> этого
>> > > пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
>> > > скиньте, плиз, линку на почту где можно подробнее почитать об
>> опасности
>> > > запуска одного мастер-процесса для разных пользователей.
>> >
>> > Это достаточно самоочевидно для любого, кто немного интересуется
>> > безопасностью.
>> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше
>> 20+.
>> > В общем когда приходит понимание, что программ без ошибок не бывает.
>> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
>> > иметь возможность читать конфиг принадлежащий любому пользователю и
>> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
>> > некторая дыра, т.к. он получается должен быть рутовым.
>> > В модели отдельного мастера на пользователя он после запуска
>> > безвозвратно дропает свои привелегии и эта схема в целом меньше
>> > подвержена протечкам.
>> [..]
>>
>> Основной процесс Unit-а, который работает от рута, не читает конфигов
>> и не взаимодействует с пользователями и их приложениями.
>>
>> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
>> также,
>> как были бы изолированы отдельные процессы php-fpm, запущенные независимо
>> друг
>> от друга на одной машине.
>>
>> --
>> Валентин Бартенев
>> ___
>> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Валентин Бартенев 
On Friday 20 October 2017 17:34:39 Виктор Вислобоков wrote:
> >> В unit главный процесс сначала форкается, а потом динамически подгружает
> нужный модуль, который слинкован с соответствующей версией php/python.
> Поэтому можно одновременно запускать разные версии языков.
> Эээ... не совсем понял.
> А вот этот "нужный модуль" это часть Unit? Если да, то каким образом
> достигается его линковка например с разными версиями PHP одновременно? Или
> это целый набор "нужных модулей" каждый под нужную нам версию PHP? Если да,
> то получается мы должны собрать каждый такой "нужный модуль" для каждой
> версии PHP которую планируем использовать?
> 
[..]

Именно так.  Одна сборка php - один модуль.

Модуль можно собрать, либо поставить из нашего репозитория, если вы используете
стандартные пакеты с php.

Если вы собираете свои пакеты с php, то просто добавляете туда сборку модуля для
unit-а, и unit сам их обнаружит и подхватит.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> В unit главный процесс сначала форкается, а потом динамически подгружает
нужный модуль, который слинкован с соответствующей версией php/python.
Поэтому можно одновременно запускать разные версии языков.
Эээ... не совсем понял.
А вот этот "нужный модуль" это часть Unit? Если да, то каким образом
достигается его линковка например с разными версиями PHP одновременно? Или
это целый набор "нужных модулей" каждый под нужную нам версию PHP? Если да,
то получается мы должны собрать каждый такой "нужный модуль" для каждой
версии PHP которую планируем использовать?

20 октября 2017 г., 17:29 пользователь Igor Sysoev  написал:

> > On 20 Oct 2017, at 17:21, Slawa Olhovchenkov  wrote:
> >
> > On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
> >
>  Так в таком случае использование unit еще выгоднее: ему не надо
> держать
> >> master-процесс для каждой версии php, не говоря о процессе для каждого
> >> пользователя.
> >> Не представляю как это будет работать.
> >> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> >> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> >> случае не получится загрузить в один веб-сервер несколько версий этого
> >> модуля.
> >
> > на самом деле загрузить-то получится (наверное, не проверял), а вот
> > активировать нужный для конкретно URL может быть проблемой.
> >
> > впрочем, возможно проблему решит правка сырцов для замены директив
> > php_* на phpXY_*.
> >
> > в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> > случае php (и я не смотрел как он решает проблему с собственно php
> > разных версий).
>
> В unit главный процесс сначала форкается, а потом динамически подгружает
> нужный модуль, который слинкован с соответствующей версией php/python.
> Поэтому можно одновременно запускать разные версии языков.
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Валентин Бартенев 
On Friday 20 October 2017 11:27:33 Anton Kiryushkin wrote:
> Простите за мою не понятливость. Но где в unit задается путь до php.ini?
> Используется сугубо тот, что был при сборке, или же можно как-то указать
> тот, с которым нужно запуститься?
> 
[..]

Пока используется тот, что был задан при сборке библиотеки php конкретной
версии.

Ближе к продакшен релизу появится возможность настраивать через конфигурацию.

Есть идея отказаться от отдельных, разбросанных где-то ini-файлов, не читать
их вообще, а сделать всю настройку единообразной через конфигурацию unit-а.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Илья Шипицин 
Валентин, посмотрите вот эти штуки ?

# grep '(warning' typescript
[src/nxt_file_cache.c:290] -> [src/nxt_file_cache.c:302]: (warning) Either
the condition 'handler==NULL' is redundant or there is possible null
pointer dereference: handler.
[src/nxt_port_socket.c:498] -> [src/nxt_port_socket.c:505]: (warning)
Either the condition 'b==NULL' is redundant or there is possible null
pointer dereference: b.


и, кажется, не работают тесты при "make tests" (вот это прямо напрашивается
в travis)

я хотел этим заняться, завал, к сожалению еще на пару месяцев

20 октября 2017 г., 19:25 пользователь Валентин Бартенев 
написал:

> On Friday 20 October 2017 16:48:31 Slawa Olhovchenkov wrote:
> > On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
> >
> > > Так в таком случае использование unit еще выгоднее: ему не надо держать
> > > master-процесс для каждой версии php, не говоря о процессе для каждого
> > > пользователя.
> > >
> > > P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем
> под
> > > каждого пользователя запускать отдельный master-процесс? Достаточно
> ведь
> > > завести для конкретного пользователя свой pool (работающий от имени
> этого
> > > пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> > > скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> > > запуска одного мастер-процесса для разных пользователей.
> >
> > Это достаточно самоочевидно для любого, кто немного интересуется
> > безопасностью.
> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше
> 20+.
> > В общем когда приходит понимание, что программ без ошибок не бывает.
> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> > иметь возможность читать конфиг принадлежащий любому пользователю и
> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> > некторая дыра, т.к. он получается должен быть рутовым.
> > В модели отдельного мастера на пользователя он после запуска
> > безвозвратно дропает свои привелегии и эта схема в целом меньше
> > подвержена протечкам.
> [..]
>
> Основной процесс Unit-а, который работает от рута, не читает конфигов
> и не взаимодействует с пользователями и их приложениями.
>
> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> также,
> как были бы изолированы отдельные процессы php-fpm, запущенные независимо
> друг
> от друга на одной машине.
>
> --
> Валентин Бартенев
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Igor Sysoev 
> On 20 Oct 2017, at 17:21, Slawa Olhovchenkov  wrote:
> 
> On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
> 
 Так в таком случае использование unit еще выгоднее: ему не надо держать
>> master-процесс для каждой версии php, не говоря о процессе для каждого
>> пользователя.
>> Не представляю как это будет работать.
>> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
>> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
>> случае не получится загрузить в один веб-сервер несколько версий этого
>> модуля.
> 
> на самом деле загрузить-то получится (наверное, не проверял), а вот
> активировать нужный для конкретно URL может быть проблемой.
> 
> впрочем, возможно проблему решит правка сырцов для замены директив
> php_* на phpXY_*.
> 
> в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> случае php (и я не смотрел как он решает проблему с собственно php
> разных версий).

В unit главный процесс сначала форкается, а потом динамически подгружает
нужный модуль, который слинкован с соответствующей версией php/python.
Поэтому можно одновременно запускать разные версии языков.


-- 
Igor Sysoev
http://nginx.com

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
также, как были бы изолированы отдельные процессы php-fpm, запущенные
независимо друг от друга на одной машине.

Тогда я пока не вижу никакой выгоды от unit'а в сравнении со связкой
nginx+php-fpm.

20 октября 2017 г., 17:25 пользователь Валентин Бартенев 
написал:

> On Friday 20 October 2017 16:48:31 Slawa Olhovchenkov wrote:
> > On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
> >
> > > Так в таком случае использование unit еще выгоднее: ему не надо держать
> > > master-процесс для каждой версии php, не говоря о процессе для каждого
> > > пользователя.
> > >
> > > P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем
> под
> > > каждого пользователя запускать отдельный master-процесс? Достаточно
> ведь
> > > завести для конкретного пользователя свой pool (работающий от имени
> этого
> > > пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> > > скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> > > запуска одного мастер-процесса для разных пользователей.
> >
> > Это достаточно самоочевидно для любого, кто немного интересуется
> > безопасностью.
> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше
> 20+.
> > В общем когда приходит понимание, что программ без ошибок не бывает.
> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> > иметь возможность читать конфиг принадлежащий любому пользователю и
> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> > некторая дыра, т.к. он получается должен быть рутовым.
> > В модели отдельного мастера на пользователя он после запуска
> > безвозвратно дропает свои привелегии и эта схема в целом меньше
> > подвержена протечкам.
> [..]
>
> Основной процесс Unit-а, который работает от рута, не читает конфигов
> и не взаимодействует с пользователями и их приложениями.
>
> Каждое приложение со своей конфигурацией полностью изолировано.  Точно
> также,
> как были бы изолированы отдельные процессы php-fpm, запущенные независимо
> друг
> от друга на одной машине.
>
> --
> Валентин Бартенев
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Валентин Бартенев 
On Friday 20 October 2017 16:48:31 Slawa Olhovchenkov wrote:
> On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
> 
> > Так в таком случае использование unit еще выгоднее: ему не надо держать
> > master-процесс для каждой версии php, не говоря о процессе для каждого
> > пользователя.
> > 
> > P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
> > каждого пользователя запускать отдельный master-процесс? Достаточно ведь
> > завести для конкретного пользователя свой pool (работающий от имени этого
> > пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> > скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> > запуска одного мастер-процесса для разных пользователей.
> 
> Это достаточно самоочевидно для любого, кто немного интересуется
> безопасностью.
> Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> В общем когда приходит понимание, что программ без ошибок не бывает.
> Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> иметь возможность читать конфиг принадлежащий любому пользователю и
> перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> некторая дыра, т.к. он получается должен быть рутовым.
> В модели отдельного мастера на пользователя он после запуска
> безвозвратно дропает свои привелегии и эта схема в целом меньше
> подвержена протечкам.
[..]

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

Каждое приложение со своей конфигурацией полностью изолировано.  Точно также,
как были бы изолированы отдельные процессы php-fpm, запущенные независимо друг
от друга на одной машине.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> на самом деле загрузить-то получится (наверное, не проверял),
не получится. ибо даже разные версии PHP используют одно и тоже
пространство имён функций и таблиц символов.

>> впрочем, возможно проблему решит правка сырцов для замены директив
Крайне в этом сомневаюсь. Если бы это было так просто, давно бы уже были
решения на эту тему, а их нет. Когда нужны разные версии в режиме mod_php
просто запускаешь второй сервер apache (здесь же) с другим модулем mod_php

20 октября 2017 г., 17:21 пользователь Slawa Olhovchenkov 
написал:

> On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
>
> > >> Так в таком случае использование unit еще выгоднее: ему не надо
> держать
> > master-процесс для каждой версии php, не говоря о процессе для каждого
> > пользователя.
> > Не представляю как это будет работать.
> > Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> > безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> > случае не получится загрузить в один веб-сервер несколько версий этого
> > модуля.
>
> на самом деле загрузить-то получится (наверное, не проверял), а вот
> активировать нужный для конкретно URL может быть проблемой.
>
> впрочем, возможно проблему решит правка сырцов для замены директив
> php_* на phpXY_*.
>
> в любом случае, nginx unit не решает проблему с pear и pecl, например, в
> случае php (и я не смотрел как он решает проблему с собственно 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:

> >> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
> Не представляю как это будет работать.
> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
> случае не получится загрузить в один веб-сервер несколько версий этого
> модуля.

на самом деле загрузить-то получится (наверное, не проверял), а вот
активировать нужный для конкретно URL может быть проблемой.

впрочем, возможно проблему решит правка сырцов для замены директив
php_* на phpXY_*.

в любом случае, nginx unit не решает проблему с pear и pecl, например, в
случае php (и я не смотрел как он решает проблему с собственно php
разных версий).
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Так в таком случае использование unit еще выгоднее: ему не надо держать
master-процесс для каждой версии php, не говоря о процессе для каждого
пользователя.
Не представляю как это будет работать.
Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом
случае не получится загрузить в один веб-сервер несколько версий этого
модуля. Или возьмём php-fpm, который сам по себе и который даёт возможность
тому же nginx'у обращаться к своему сокету или порту, этих может быть до
лешего версий, но тогда каждый из них является по сути самостоятельным
процессом.

>> Проблема слегка преувеличена и, если бы все были настолько
параноидальными в безопасности - мы бы до сих пор не увидели систем
виртуализации
Скорее преуменьшена :)
С виртуализацией несколько по-другому дело обстоит и сравнивать в данном
случае некорректно.

20 октября 2017 г., 16:42 пользователь Maksim Kulik 
написал:

> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
>
> P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
> каждого пользователя запускать отдельный master-процесс? Достаточно ведь
> завести для конкретного пользователя свой pool (работающий от имени этого
> пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> запуска одного мастер-процесса для разных пользователей.
>
> 20 октября 2017 г., 16:36 пользователь Виктор Вислобоков <
> corocho...@gmail.com> написал:
>
>> >> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
>> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
>> php-fpm, который, как минимум, кушает память, сокет и т.д.
>>
>> На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
>> php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
>> php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
>> всё-равно его запускать придётся. Так что если используется php-fpm то
>> никакой экономии ресурсов не будет
>>
>>>
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Pavel V. 
Здравствуйте, Maksim.

Вы писали 20 октября 2017 г., 20:42:54:

> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого 
> пользователя.
> Если я ошибаюсь - скиньте, плиз, линку на почту где можно подробнее почитать 
> об опасности
> запуска одного мастер-процесса для разных пользователей.

Помнится мне, opcache держит кеш в shared memory, создаваемой родительским
процессом, и, соответственно, общей для всех дочерних процессов - для всех 
пулов.

Именно из-за этого мы делаем отдельный fpm instance для каждого _собственного_ 
проекта.

Поправьте меня, если заблуждаюсь...

> На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
> php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
> php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
> всё-равно его запускать придётся. Так что если используется php-fpm то 
> никакой экономии ресурсов не будет

-- 
С уважением,
 Pavel  mailto:pavel2...@ngs.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 04:58:26PM +0300, Maksim Kulik wrote:

> Н... в таком случае unit и писать не надо. Это ж будет один
> мастер-процесс, который будет работать под рутом и иметь доступ к данным
> вообще всех сайтов. Проблема слегка преувеличена и, если бы все были
> настолько параноидальными в безопасности - мы бы до сих пор не увидели
> систем виртуализации, т.к. во всех таких системах есть тот, кто имеет
> доступ ко всем виртуалкам одновременно и в нем 100% есть ошибки, которые
> потенциально могут позволить получить доступ к нему из виртуальной среды,
> ну а там уже и ко всему серверу.

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

> P.S. Я не утверждаю, что это правильный подход, но ради
> быстродействия/удобства/цены можно в некоторых случаях снизить планку
> безопасности.

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

а вот если их 100500, а молотят в один момент только 10 из них -- то
все уже несколько иначе.

удобство -- вообще отдельный вопрос.

> > Это достаточно самоочевидно для любого, кто немного интересуется
> > безопасностью.
> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> > В общем когда приходит понимание, что программ без ошибок не бывает.
> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> > иметь возможность читать конфиг принадлежащий любому пользователю и
> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> > некторая дыра, т.к. он получается должен быть рутовым.
> > В модели отдельного мастера на пользователя он после запуска
> > безвозвратно дропает свои привелегии и эта схема в целом меньше
> > подвержена протечкам.
> > ___
> > 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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Andrey Velikoredchanin 
20 октября 2017 г., 16:00 пользователь Илья Шипицин 
написал:

>
>
> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
> unclean...@gmail.com> написал:
>
>> Очень интересная штука! Обязательно будем пробовать.
>>
>
> можно поподробнее, чем именно интересна ?
>

Для меня unit интересен возможностью прозрачного апгрейда сайта без обрыва
имеющихся коннектов.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Maksim Kulik 
Н... в таком случае unit и писать не надо. Это ж будет один
мастер-процесс, который будет работать под рутом и иметь доступ к данным
вообще всех сайтов. Проблема слегка преувеличена и, если бы все были
настолько параноидальными в безопасности - мы бы до сих пор не увидели
систем виртуализации, т.к. во всех таких системах есть тот, кто имеет
доступ ко всем виртуалкам одновременно и в нем 100% есть ошибки, которые
потенциально могут позволить получить доступ к нему из виртуальной среды,
ну а там уже и ко всему серверу.

P.S. Я не утверждаю, что это правильный подход, но ради
быстродействия/удобства/цены можно в некоторых случаях снизить планку
безопасности.


> Это достаточно самоочевидно для любого, кто немного интересуется
> безопасностью.
> Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> В общем когда приходит понимание, что программ без ошибок не бывает.
> Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> иметь возможность читать конфиг принадлежащий любому пользователю и
> перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> некторая дыра, т.к. он получается должен быть рутовым.
> В модели отдельного мастера на пользователя он после запуска
> безвозвратно дропает свои привелегии и эта схема в целом меньше
> подвержена протечкам.
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Никита Козлов 
20 октября 2017 г., 16:48 пользователь Slawa Olhovchenkov 
написал:
>
> Это достаточно самоочевидно для любого, кто немного интересуется
> безопасностью.
> Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> В общем когда приходит понимание, что программ без ошибок не бывает.
> Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> иметь возможность читать конфиг принадлежащий любому пользователю и
> перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> некторая дыра, т.к. он получается должен быть рутовым.
> В модели отдельного мастера на пользователя он после запуска
> безвозвратно дропает свои привелегии и эта схема в целом меньше
> подвержена протечкам.


Наверное unit больше для микросервисных приложений которые уже давно
пишутся на разных языках (у одного приложения могут быть сервисы написанные
на разных языках), а не для массового хостинга. Если думать в этом ключе,
то выгода становится очевидной.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Slawa Olhovchenkov 
On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:

> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
> 
> P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
> каждого пользователя запускать отдельный master-процесс? Достаточно ведь
> завести для конкретного пользователя свой pool (работающий от имени этого
> пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
> скиньте, плиз, линку на почту где можно подробнее почитать об опасности
> запуска одного мастер-процесса для разных пользователей.

Это достаточно самоочевидно для любого, кто немного интересуется
безопасностью.
Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
В общем когда приходит понимание, что программ без ошибок не бывает.
Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
иметь возможность читать конфиг принадлежащий любому пользователю и
перезапускать пул(ы) от любого пользовательского UID, а это уже есть
некторая дыра, т.к. он получается должен быть рутовым.
В модели отдельного мастера на пользователя он после запуска
безвозвратно дропает свои привелегии и эта схема в целом меньше
подвержена протечкам.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Peter B. Pokryshev 
On Fri, 20 Oct 2017 16:29:57 +0300
Maksim Kulik  wrote:

> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
> php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
> и мониторить надо на предмет доступности. Добавим сюда возможность
> изменения конфигурации "на лету" без перезапуска рабочих процессов (на
> случай перевода одного из 500 сайтов на другую версию PHP) - и мы получим
> очень удобную замену нынешним костылям по крайней мере для хостеров.
> 

Привет.
Да, крутая тема, но вот что делать с апачёвым mod_rewrite хостеру...
Это получается чтобы у клиента он заработал, ему надо 
пихнуть свои правила куда-то в панели управления, откуда эти правила хостер 
конвертит в правила nginx? Или я всё проспал и такой проблемы уже нет?

> 20 октября 2017 г., 16:00 пользователь Илья Шипицин 
> написал:
> 
> >
> >
> > 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
> > unclean...@gmail.com> написал:
> >
> >> Очень интересная штука! Обязательно будем пробовать.
> >>
> >
> > можно поподробнее, чем именно интересна ?
> > возможность запускать php или go - есть, всякие там php-fpm, caddy, ...
> >
> > понятно, что, скорее всего на unit тоже будет работать. а в чем
> > преимущество, в двух словах?
> >
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >


-- 
Peter B. Pokryshev 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Maksim Kulik 
Так в таком случае использование unit еще выгоднее: ему не надо держать
master-процесс для каждой версии php, не говоря о процессе для каждого
пользователя.

P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
каждого пользователя запускать отдельный master-процесс? Достаточно ведь
завести для конкретного пользователя свой pool (работающий от имени этого
пользователя), а мастер-процесс будет всегда один. Если я ошибаюсь -
скиньте, плиз, линку на почту где можно подробнее почитать об опасности
запуска одного мастер-процесса для разных пользователей.

20 октября 2017 г., 16:36 пользователь Виктор Вислобоков <
corocho...@gmail.com> написал:

> >> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
> php-fpm, который, как минимум, кушает память, сокет и т.д.
>
> На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
> php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
> php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
> всё-равно его запускать придётся. Так что если используется php-fpm то
> никакой экономии ресурсов не будет
>
>>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Виктор Вислобоков 
>> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
установлено 5 версий PHP. Для каждой версии должен быть master-процесс
php-fpm, который, как минимум, кушает память, сокет и т.д.

На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
php-fpm процесс, иначе это не безопасность будет а решето! А раз отдельный
php-fpm процесс со своим userid то и не важно какой версии PHP он будет -
всё-равно его запускать придётся. Так что если используется php-fpm то
никакой экономии ресурсов не будет

20 октября 2017 г., 16:29 пользователь Maksim Kulik 
написал:

> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
> php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
> и мониторить надо на предмет доступности. Добавим сюда возможность
> изменения конфигурации "на лету" без перезапуска рабочих процессов (на
> случай перевода одного из 500 сайтов на другую версию PHP) - и мы получим
> очень удобную замену нынешним костылям по крайней мере для хостеров.
>
> 20 октября 2017 г., 16:00 пользователь Илья Шипицин 
> написал:
>
>>
>>
>> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
>> unclean...@gmail.com> написал:
>>
>>> Очень интересная штука! Обязательно будем пробовать.
>>>
>>
>> можно поподробнее, чем именно интересна ?
>> возможность запускать php или go - есть, всякие там php-fpm, caddy, ...
>>
>> понятно, что, скорее всего на unit тоже будет работать. а в чем
>> преимущество, в двух словах?
>>
>> ___
>> 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Maksim Kulik 
Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
установлено 5 версий PHP. Для каждой версии должен быть master-процесс
php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
и мониторить надо на предмет доступности. Добавим сюда возможность
изменения конфигурации "на лету" без перезапуска рабочих процессов (на
случай перевода одного из 500 сайтов на другую версию PHP) - и мы получим
очень удобную замену нынешним костылям по крайней мере для хостеров.

20 октября 2017 г., 16:00 пользователь Илья Шипицин 
написал:

>
>
> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
> unclean...@gmail.com> написал:
>
>> Очень интересная штука! Обязательно будем пробовать.
>>
>
> можно поподробнее, чем именно интересна ?
> возможность запускать php или go - есть, всякие там php-fpm, caddy, ...
>
> понятно, что, скорее всего на unit тоже будет работать. а в чем
> преимущество, в двух словах?
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Andrey Velikoredchanin 
Очень интересная штука! Обязательно будем пробовать.

20 октября 2017 г., 11:27 пользователь Anton Kiryushkin 
написал:

> Простите за мою не понятливость. Но где в unit задается путь до php.ini?
> Используется сугубо тот, что был при сборке, или же можно как-то указать
> тот, с которым нужно запуститься?
>
> 2017-10-20 10:42 GMT+03:00 Igor Sysoev :
>
>> http://unit.nginx.org
>>
>> Changes with Unit 0.219 Oct
>> 2017
>>
>>*) Feature: Go package improvements.
>>
>>*) Feature: configuration persistence.
>>
>>*) Feature: improved handling of configuration errors.
>>
>>*) Feature: application "timeout" property.
>>
>>*) Bugfix: Go application crashed under load.
>>
>>*) Bugfix: POST request for PHP were handled incorrectly.
>>
>>*) Bugfix: the router exited abnormally if all listeners had been
>>   deleted.
>>
>>*) Bugfix: the router crashed under load.
>>
>>*) Bugfix: memory leak in the router.
>>
>>
>> --
>> Igor Sysoev
>> http://nginx.com
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>
> ___
> 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

Re: unit-0.2 beta release

2017-10-20 Пенетрантность Anton Kiryushkin 
Простите за мою не понятливость. Но где в unit задается путь до php.ini?
Используется сугубо тот, что был при сборке, или же можно как-то указать
тот, с которым нужно запуститься?

2017-10-20 10:42 GMT+03:00 Igor Sysoev :

> http://unit.nginx.org
>
> Changes with Unit 0.219 Oct
> 2017
>
>*) Feature: Go package improvements.
>
>*) Feature: configuration persistence.
>
>*) Feature: improved handling of configuration errors.
>
>*) Feature: application "timeout" property.
>
>*) Bugfix: Go application crashed under load.
>
>*) Bugfix: POST request for PHP were handled incorrectly.
>
>*) Bugfix: the router exited abnormally if all listeners had been
>   deleted.
>
>*) Bugfix: the router crashed under load.
>
>*) Bugfix: memory leak in the router.
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Best regards,
Anton Kiryushkin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru