On Saturday, 16 December 2017 16:05:22 MSK Валентин Бартенев wrote:
> On Friday, 15 December 2017 21:53:57 MSK Иван wrote:
> > Прекрасная новость!
> >
> > А пакеты для debian9? А когда планируется релиз?
> >
> [..]
>
> Пакеты для Debian надеюсь сделаем до конца года.
> Релиз запланирован на втор
On Friday, 15 December 2017 21:53:57 MSK Иван wrote:
> Прекрасная новость!
>
> А пакеты для debian9? А когда планируется релиз?
>
[..]
Пакеты для Debian надеюсь сделаем до конца года.
Релиз запланирован на второй квартал 2018.
--
Валентин Бартенев
___
Прекрасная новость!
А пакеты для debian9? А когда планируется релиз?
В письме от пятница, 15 декабря 2017 г. 20:37:37 MSK пользователь Валентин
Бартенев написал:
> On Friday 15 December 2017 17:57:42 Иван wrote:
> [..]
>
> > А интеграция ruby в ближних планах есть?
>
> В первом квартале 2018 п
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/mailma
Здравствуйте!
В письме от пятница, 20 октября 2017 г. 22:58:00 MSK пользователь Igor Sysoev
написал:
>
> С точки зрения юнита, языки делятся на две категории:
> 1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют
> некий
стандартный интерфейс для встраивания в веб-сервер;
>
20 октября 2017 г., 18:44 пользователь Slawa Olhovchenkov
написал:
> тут проблема со стандартным путями получения pear/pecl слинкованными с
> разными версиями php. мне как-то не известны дистрибутивы,
> предоставляющие это из коробки.
Но всегда можно подключить альтернативные репозитории в духе
h
On Friday 20 October 2017 22:30:41 Vadim A. Misbakh-Soloviov wrote:
> > - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
> >счет своей архитектуры.
> >
>
> Я что-то недопонял...
>
> Данное утверждение предполагает использование Unit без NginX перед ним?..
Да.
--
Вале
> On Oct 20, 2017, at 08:30, Vadim A. Misbakh-Soloviov wrote:
>
>> - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>> счет своей архитектуры.
>>
>
> Я что-то недопонял...
>
> Данное утверждение предполагает использование Unit без NginX перед ним?..
Существуют разные
Да, unit будет оставаться доступным по лицензии Apache 2.0.
Все текущие функции будут оставаться открытыми.
--
Nick Shadrin / Sr. Product Manager / n...@nginx.com
> On Oct 24, 2017, at 01:49, Andrey Velikoredchanin
> wrote:
>
> Вопрос разработчикам nginx unit - его лицензия будет оставаться
Вопрос разработчикам nginx unit - его лицензия будет оставаться открытой в
будущем? Будет-ли версия Enterprise и чем она будет отличаться от открытой?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
> - Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>счет своей архитектуры.
>
Я что-то недопонял...
Данное утверждение предполагает использование Unit без NginX перед ним?..
___
nginx-ru mailing list
nginx-ru@nginx.org
http:/
On Fri, Oct 20, 2017 at 10:41:41PM +0300, Виктор Вислобоков wrote:
> >> нет. на самом деле все сильно зависит от того, что происходит на каждый
> запрос внутри php. вполне возможно, что разницей между mod_php и php-fpm
> можно просто пренебречь.
> Простите, но я же не голословно говорю.
> Пытались
Igor Sysoev wrote:
С точки зрения юнита, языки делятся на две категории:
1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют некий
стандартный интерфейс для встраивания в веб-сервер;
2) встраивание модуля юнита в приложение: Go, Node.js, Java.
Спасибо. Была бы очень кстати к
> On 20 Oct 2017, at 22:50, Andrey Oktyabrskiy wrote:
>
> Andrey Velikoredchanin wrote:
>> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват,
>> но на нем еще много чего написано и пишется.
> Я бы обобщил вопрос: насколько сложно пришить к юниту новый интерпретатор?
С точки
Andrey Velikoredchanin wrote:
Кстати, а для perl предвидится реализация модуля? Он, конечно, староват,
но на нем еще много чего написано и пишется.
Я бы обобщил вопрос: насколько сложно пришить к юниту новый интерпретатор?
___
nginx-ru mailing list
ngi
>> нет. на самом деле все сильно зависит от того, что происходит на каждый
запрос внутри php. вполне возможно, что разницей между mod_php и php-fpm
можно просто пренебречь.
Простите, но я же не голословно говорю.
Пытались мы, не один раз пытались, крутили все ручки, делали что только
можно, но php-
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, а вот
>
> 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.o
Я уже подымал эту тему на Github
https://github.com/nginx/unit/issues/6
Будет хорошо создать здесь отдельные maillist для Unit.
Я согласен с теми кто считает что Unit сложно будет конкурировать с
PHP-FPM.
1. Простота в настройке и запуске разных версий РНР - это совсем не сложно,
есть пакеты Rem
Здравствуйте, Andrey.
Вы писали 21 октября 2017 г., 0:33:01:
> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
> на нем еще много чего написано и пишется.
Было бы интересно.
--
С уважением,
Pavel mailto:pavel2...@ngs.ru
___
Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, но
на нем еще много чего написано и пишется.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> nginx + php-fpm возможно выигрывает у nginx + apache/mod_php, но
скореепо вине сложности правильной настройки последнего под данный
микробенчмарк.
Не так. nginx+php-fpm НАМНОГО выигрывает у nginx+apache/mod_php, а вот
nginx+apache/fastCGI просто выигрывает у mod_php, хотя и ненамного.
И выигрыва
On Friday 20 October 2017 18:21:35 Виктор Вислобоков wrote:
>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
>> счет своей архитектуры.
> Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так
> что не вижу за счёт чего.
> Хочу увидеть сравнительные тесты
>> А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
в минуту и соединениями, живущими сутками, из-за которых в памяти висят
тысячи воркеров.
Согласен, как и есть проекты, которые выносят функциональность nginx на
уровень ядра Linux :)
Специфика проектов бывает разная, кто бы
> On 20 Oct 2017, at 18:21, Виктор Вислобоков wrote:
>
> Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно.
В 2002 году я тоже так думал.
А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз
в минуту и соединениями, живущими сутками, из-за которых в па
>> Unit будет быстрее nginx+php-fpm и тратить меньше ресурсов просто за
счет своей архитектуры.
Очень спорное утверждение. fastCGI всегда выигрывало в споре с mod_php, так
что не вижу за счёт чего.
Хочу увидеть сравнительные тесты.
>> Меньше движущихся частей. Unit требует меньше настройки и прис
On Friday 20 October 2017 17:27:30 Виктор Вислобоков wrote:
> >> Каждое приложение со своей конфигурацией полностью изолировано. Точно
> также, как были бы изолированы отдельные процессы php-fpm, запущенные
> независимо друг от друга на одной машине.
>
> Тогда я пока не вижу никакой выгоды от uni
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-процесс
> On 20 Oct 2017, at 17:34, Виктор Вислобоков wrote:
>
> >> В unit главный процесс сначала форкается, а потом динамически подгружает
> >> нужный модуль, который слинкован с соответствующей версией php/python.
> >> Поэтому можно одновременно запускать разные версии языков.
> Эээ... не совсем по
и вот, кажется, интересные штуки
# 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 po
On Friday 20 October 2017 17:34:39 Виктор Вислобоков wrote:
> >> В unit главный процесс сначала форкается, а потом динамически подгружает
> нужный модуль, который слинкован с соответствующей версией php/python.
> Поэтому можно одновременно запускать разные версии языков.
> Эээ... не совсем понял.
>
>> В unit главный процесс сначала форкается, а потом динамически подгружает
нужный модуль, который слинкован с соответствующей версией php/python.
Поэтому можно одновременно запускать разные версии языков.
Эээ... не совсем понял.
А вот этот "нужный модуль" это часть Unit? Если да, то каким образом
On Friday 20 October 2017 11:27:33 Anton Kiryushkin wrote:
> Простите за мою не понятливость. Но где в unit задается путь до php.ini?
> Используется сугубо тот, что был при сборке, или же можно как-то указать
> тот, с которым нужно запуститься?
>
[..]
Пока используется тот, что был задан при сбор
Валентин, посмотрите вот эти штуки ?
# 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]
> On 20 Oct 2017, at 17:21, Slawa Olhovchenkov wrote:
>
> On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
>
Так в таком случае использование unit еще выгоднее: ему не надо держать
>> master-процесс для каждой версии php, не говоря о процессе для каждого
>> пользователя.
>
>> Каждое приложение со своей конфигурацией полностью изолировано. Точно
также, как были бы изолированы отдельные процессы 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, не говоря о процессе для каждого
> > пользователя.
>
>> на самом деле загрузить-то получится (наверное, не проверял),
не получится. ибо даже разные версии PHP используют одно и тоже
пространство имён функций и таблиц символов.
>> впрочем, возможно проблему решит правка сырцов для замены директив
Крайне в этом сомневаюсь. Если бы это было так просто,
On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote:
> >> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
> Не представляю как это будет работать.
> Возьмём mod_php для ап
>> Так в таком случае использование unit еще выгоднее: ему не надо держать
master-процесс для каждой версии php, не говоря о процессе для каждого
пользователя.
Не представляю как это будет работать.
Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а
безопасность обеспечивает скаж
Здравствуйте, Maksim.
Вы писали 20 октября 2017 г., 20:42:54:
> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
> Если я ошибаюсь - скиньте, плиз, линку на почту где можно подробнее п
On Fri, Oct 20, 2017 at 04:58:26PM +0300, Maksim Kulik wrote:
> Н... в таком случае unit и писать не надо. Это ж будет один
> мастер-процесс, который будет работать под рутом и иметь доступ к данным
> вообще всех сайтов. Проблема слегка преувеличена и, если бы все были
> настолько параноидальн
20 октября 2017 г., 16:00 пользователь Илья Шипицин
написал:
>
>
> 20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
> unclean...@gmail.com> написал:
>
>> Очень интересная штука! Обязательно будем пробовать.
>>
>
> можно поподробнее, чем именно интересна ?
>
Для меня unit интересен
Н... в таком случае unit и писать не надо. Это ж будет один
мастер-процесс, который будет работать под рутом и иметь доступ к данным
вообще всех сайтов. Проблема слегка преувеличена и, если бы все были
настолько параноидальными в безопасности - мы бы до сих пор не увидели
систем виртуализации,
20 октября 2017 г., 16:48 пользователь Slawa Olhovchenkov
написал:
>
> Это достаточно самоочевидно для любого, кто немного интересуется
> безопасностью.
> Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> В общем когда приходит понимание, что программ без ошибок не бывае
On Fri, Oct 20, 2017 at 04:42:54PM +0300, Maksim Kulik wrote:
> Так в таком случае использование unit еще выгоднее: ему не надо держать
> master-процесс для каждой версии php, не говоря о процессе для каждого
> пользователя.
>
> P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем
On Fri, 20 Oct 2017 16:29:57 +0300
Maksim Kulik wrote:
> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
> установлено 5 версий PHP. Для каждой версии должен быть master-процесс
> php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
> и мониторить надо
Так в таком случае использование unit еще выгоднее: ему не надо держать
master-процесс для каждой версии php, не говоря о процессе для каждого
пользователя.
P.S. Может я немного отстал от актуальных знаний о PHP-FPM, но зачем под
каждого пользователя запускать отдельный master-процесс? Достаточно
>> Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
установлено 5 версий PHP. Для каждой версии должен быть master-процесс
php-fpm, который, как минимум, кушает память, сокет и т.д.
На виртуальном хостинге для КАЖДОГО клиента должен быть запущен ОТДЕЛЬНЫЙ
php-fpm процесс, иначе
Экономия ресурсов, например. Возьмем виртуальный хостинг, на котором
установлено 5 версий PHP. Для каждой версии должен быть master-процесс
php-fpm, который, как минимум, кушает память, сокет и т.д. В идеале его еще
и мониторить надо на предмет доступности. Добавим сюда возможность
изменения конфиг
20 октября 2017 г., 13:45 пользователь Andrey Velikoredchanin <
unclean...@gmail.com> написал:
> Очень интересная штука! Обязательно будем пробовать.
>
можно поподробнее, чем именно интересна ?
возможность запускать php или go - есть, всякие там php-fpm, caddy, ...
понятно, что, скорее всего на
Очень интересная штука! Обязательно будем пробовать.
20 октября 2017 г., 11:27 пользователь Anton Kiryushkin
написал:
> Простите за мою не понятливость. Но где в unit задается путь до php.ini?
> Используется сугубо тот, что был при сборке, или же можно как-то указать
> тот, с которым нужно запус
Простите за мою не понятливость. Но где в unit задается путь до php.ini?
Используется сугубо тот, что был при сборке, или же можно как-то указать
тот, с которым нужно запуститься?
2017-10-20 10:42 GMT+03:00 Igor Sysoev :
> http://unit.nginx.org
>
> Changes with Unit 0.2
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.
*) B
54 matches
Mail list logo
