По умолчанию он был выключен только относительно недавно, в последних версиях. До этого был по умолчанию включен. А ещё многие начитавшись всяких статеек любили добавлять accept_mutex on.
Собственно одной из причин его выключить было, что нам надоели горе-бенчмаркеры, которые запускают nginx и после запуска, без нагрузки рабочие процессы отключают нотификацию о новых соединениях и уходят спать на accept_mutex_delay. После чего бенчмаркер запускает свой славный микробенчмарк и все соединения ловятся одним рабочим процессом, поскольку другие отключили нотификацию.
Почему один процесс NGINX берёт на себя всю работу?
Потому что accept_mutex включен. Выключите и будет счастье.
В случае epoll-and-accept алгоритм другой: Linux, кажется, выбирает процесс, который был добавлен в очередь ожидания новых соединений последним, т.е. LIFO.
AFAIK, с флагом EPOLLEXCLUSIVE это не так и ждуны добавляются в конец очереди.
В попытках делать на лету то, что при грамотном подходе должно происходить единожды при развертывании новой версии сайта, может легко привести к крайне низкой производительности, высокому потреблению памяти и проблемам со стабильностью. Зато попугаи в неком сервисе будут радовать глаз и не важно, что сайт тормозит и ложиться под нагрузкой.
Сейчас Go планируется ставить из пакета, версия которого будет всегда совпадать с версией юнита в репозитории. В случае github разработчик будет вынужден сам следить за тем, чтобы клонировался нужный бранч. Неужели так удобнее? Пакетный менеджер придумали специально чтобы этим не заниматься.
Это не CGI запускалка. У нас собственный SAPI модуль для php по типу как php-fpm, так что потенциально всё должно работать, включая opcache и кэш соединений. Сейчас opcache уникален для каждого процесса, позже научим юнит разделяемому между процессами кэшу.
На данный момент там много всякого дебага и часть кода написана в стиле «proof-of-concept». Сейчас сравнивать производительность бессмысленно. Но архитектура спроектирована так, чтобы добавлять минимум накладных расходов и выжать максимум из приложений. К моменту выпуска первой стабильной версии доведем до ума и можно будет тестировать.
Да, планируется поддержка расширение возможностей, как для самих запускаемых языков, так и обвязки в целом. Важность virtualenv прекрасно понимаю, всё будет.
Такая возможность будет. Пока мы в стадии ранней беты, но планируем довести стабильность и функциональность до хорошего состояния и выпустить осмысленный релиз в начале 2018. Сейчас можно просто покрутить, поиграться, написать побольше фичреквестов.
Сокеты это лишние накладные расходы. Там все сложнее. Он общается с процессами юнита посредством нашего RPC, который построен на разделяемой памяти. Модуль как раз подсоединяет приложение на Go к этому RPC, когда запускается процессом юнита.
Application на python — это собственно сам набор python скриптов, их собирать не надо, они компилируются в опкод самим cpython. Для запуска ваших .py скриптов с нужной версией cpython необходимы лишь соответствующие модули для юнита собранные с соответствующими версиями cpython. Пакеты с модулями юнита можно установить из репозитория, либо собрать самостоятельно.
Во многих дистрибутивах сейчас как минимум две версии cpython, ветки 2 и ветки 3. Соответственно и пакеты для них мы будем собирать сами, либо это будут делать майнтейнеры дистрибутива.
А если вам нужен какой-то особенный cpython, которого нет в репозиториях, то вы же его собираете так или иначе. Просто соберите динамический модуль для юнита с ним и юнит сможет его загружать и использовать для запуска ваших приложений на пайтоне.
Например, как при помощи nginx application можно будет запустить проекты, которые требует разные версии одной библиотеки?
В статье выше люди запускают две разных версии PHP, каждая использует свою собственную libphp.so (которые в свою очередь могли быть собраны со своими зависимостями). Я запускал одновременно приложения на 3-х разных версиях PHP, 2-х версиях Python и Go. Вообще это ни чем не ограничено.
Да.
По умолчанию он был выключен только относительно недавно, в последних версиях. До этого был по умолчанию включен. А ещё многие начитавшись всяких статеек любили добавлять
accept_mutex on.Собственно одной из причин его выключить было, что нам надоели горе-бенчмаркеры, которые запускают nginx и после запуска, без нагрузки рабочие процессы отключают нотификацию о новых соединениях и уходят спать на
accept_mutex_delay. После чего бенчмаркер запускает свой славный микробенчмарк и все соединения ловятся одним рабочим процессом, поскольку другие отключили нотификацию.AFAIK, с флагом EPOLLEXCLUSIVE это не так и ждуны добавляются в конец очереди.
По поводу бенчмарков ответил выше.
ebuild конечно хорошо было бы сделать и положить в репозиторий дженту.
Во многих дистрибутивах сейчас как минимум две версии cpython, ветки 2 и ветки 3. Соответственно и пакеты для них мы будем собирать сами, либо это будут делать майнтейнеры дистрибутива.
А если вам нужен какой-то особенный cpython, которого нет в репозиториях, то вы же его собираете так или иначе. Просто соберите динамический модуль для юнита с ним и юнит сможет его загружать и использовать для запуска ваших приложений на пайтоне.
Магия и секретные технологии. =)