Представлен (http://mailman.nginx.org/pipermail/unit/2018-November/000083...) выпуск сервера приложений NGINX Unit 1.6 (http://unit.nginx.org/), в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go и JavaScript/Node.js). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется (https://github.com/nginx/unit) под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе (https://www.opennet.dev/opennews/art.shtml?num=48434) первого выпуска.
Основное внимание при подготовке новой версии было сосредоточено на улучшении работы модуля поддержки платформы Node.js и обеспечении его совместимости с различными приложениями. Сборочная команда "make install" теперь устанавливает модуль к Node.js, если он отмечен для сборки. В скрипт "configure" также добавлена опция "--local" для локальной установки модуля Node.js.URL: http://mailman.nginx.org/pipermail/unit/2018-November/000083...
Новость: https://www.opennet.dev/opennews/art.shtml?num=49619
Господа,Кто использовал? СтОит, не стОит? Поделитесь пожалуйста впечатлениями. )
Сейчас в kubernetes приходится делать nginx sidecar в pod, чтобы проксировать в uwsgi приложение.
С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.Однозначно стоит.
Во-первых, у приложения интерфейс не uwsgi, а WSGI. usgi — это одна из реализаций wsgi application server-а и одноименный бинарный протокол, придуманный авторами uswgi.
Во-вторых, большинство wsgi app-серверов (включая uwsgi) умеют отвечать по http.
>С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.Вообще-то uwsgi может выступать в качестве веб-сервера. По сему в связке nginx + uwsgi, nginx лишний.
Оу, у нас иксперды в треде
Подселять по энжиниксу к каждому экземпляру uwsgi действительно излине. Большую часть того, что бэкендеры обычно хотят от творения Сысоева, успешно можно сделать средствами uwsgi (рерайты, редиректы, работа с заголовками итд). Остальное уже спокойно делается на тех энжиниксах, которые балансируют нагрузку между бэкендами (тем более, что у любителя энжиникса в сайдкарах по определению кубернетес и, скорее всего, используются ингрессы с энжиниксом)
а пайтоновские фреймворки сами как веб сервер не умеют запускаться?зачем там нужен нгинкс в каждом контейнере?
нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет?
Так посмотри на список поддерживаемых языков/платформ:> Python, PHP, Perl, Ruby, Go и JavaScript/Node.js
Пихон, пых, устаревший перл, нескучный руби, го-секта и вспомнити лефтпад.
Я бы дождался поддержки Java для начала. С ее появлением уже может пойти речь о чем-то взрослом, серьезном.
> Python, PHP, Perl, Ruby, Go и JavaScript/Node.jsМэйнстрим, суперпопулярный, стабильная классика, популярный с отдельных кругах, активно развиваемый суперкорпорацией, суперпопулярный среди молодежи.
Да кому она нужна ваша дырявая и сдыхающая жаба?
А вот и любители смузи-динамических языков подъехали. Ну как там, электрон оперативку жрет?
Под Явой весь корпоративный сектор, более того, на Яву меняют, тихо но уверенно, всё, что написано на Коболе, а это вся фин.индустрия мира. Но в шалашах по клепанию всяких свистоперделок для вебни об этом не в курсе, у них там полный смузи электрон по самые гланды.
На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься.
Дя-дя, букенд там у него на других языках. Вся ява там крутится на серверах приложений, которые в шкафах от оракела или ибма исполняются, а не на "других языках".
И в качестве букенда стоят rdbms-ы. И никаких "других языков" типа C++ и, тем более, всяких смузи-электронов, там нет и в помине.
> На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься#s/бэкенд/фронтэд/
Не, фронтенд там nginx обычно (я не про браузер-сайд).
Прошу заметить, что в обсуждаемых архитектурах может быть несколько пар фронтенд/бэкенд, все зависит от уровня абстракции и вероятно вы доказываете одну точку зрения оперируя информацией о разных слоях одной архитектуры.
Это ты хорошо яву с коболом сравнил. Звиняй, для реального мира навозная яма в которой копошатся банкиры и финансисты со своими коболами, жавами, 1C и оракалами совершенно побоку, тем более как ориентир для выбора технологий. Это не взрослость, это просто узкоспецифичная вонючая навозная яма. Реальный мир выбирает работающие технологии, а не ынтерпрайзную маркетинговую лапшу.
>> Реальный мир выбирает работающие технологииЧуть-чуть не проговорился про docker, вот смешно было бы, в контексте разговора про "работающие технологии".
Эти "работающие технологии" меняются раз в пять лет. А Кобол с Явой как были так и остаются. Более того, именно они прокручивают самые ответственные системы мира этого. Но смузиедам с докером и электроном головного мозга этог не понять, не доросли.
> они прокручивают самые ответственные системы мира этого.Не поэтому ли ли он в опе? :D
>>Не поэтому ли ли он в опе? :DПо всем аспектам, прежде всего по количеству бабла, которое крутится в индустрии того (энтерпрайзного) софта (и по зарплатам тамошних разрабов), и по сложности и масштабности систем, которые этим софтом представлены, там всё в порядке. Ну а смузи-электронщикам только и остаётся убеждать себя в обратном.
Тут нужно просто понимать инфантильную подростковую психологию, не более.Вопрос не в языке X(икс), который популярен по тем или иным причинам в своей нише, а в детской нежной психике, которая не может этот факт адекватно воспринимать без обид и как результат - вызывает отрицание.
Я вот не могу понять, что такого обидного в том, что некий язык X занимает определенную нишу.
Особенно смешно выглядят глупые предложения сменить X на Y без участия здравого смысла.Создавайте решения на своем любимом ЯП которые смогут составлять конкуренцию имеющемуся ПО.
Очевидно, что "хаять" язык Х на форумах значительно проще, чем "создавать решения".Нравится это местным анонимам или нет, но Жава живее всех живых. Кто не видел энтерпрайза, разуйте глаза и осознайте, что весь Андройд на жаве.
Поэтому хоть ты 200 раз напиши "Не поэтому ли ли он в опе?" не менят действительности.
Более чем уверен, что когда первое место займет язык Y, начнут перемывать кости ему.
Завистливае дети они такие.
Поддержка Java активно разрабатывается:
https://github.com/mar0x/unit/tree/java/src/javaУже даже можно начинать пробовать и оставлять отзывы. Приложения на Spring (Boot) будут работать из коробки: https://github.com/nginx/unit/issues/31#issuecomment-435018408
Скоро инструкцию туда положим.
Спасибо, это хорошая новость.А можно поинтересоваться, почему начали именно с языков семейства "пыхоплеяда"? Я тут помнится выражал мнение, что вы начали с самых тормознутых языков, -- тушить, так сказать, пожары, устроенные пыхерами. А в Java-экосистеме и без юнита все хорошо (но с юнитом станет лучше благодаря выносу работы с протоколом на уровень ниже). Но хотелось бы услышать с первых уст.
Потому что там, где повсеместно используется ява, быстро внедрять nginx unit все равно не начнут в силу консерватизма.
Я не знаю, но могу предположить.
Интеграция того же php элементарна - пишется свой sapi-модуль и готово.
А вот интегрировать с jvm их протокол на основе shared memory - это задача на порядок сложнее.
Это семейство языков имеет простой API для веб-приложений и легко интегрируется. Написать обертку очень просто, речь идет о считанных днях разработки. Над Java работа идет уже несколько месяцев и где-то столько же ещё впереди.Кроме того, практически вся Java - это различный энтерпрайз и вход туда требует гораздо больше начальных усилий. И то, что по-русски называется "минимально жизнеспособный продукт" - также требует больше усилий, чем, например, личный бложик на вордпрессе запускать.
Чего там хорошо в этой яве? До сих пор на аппсерверах все сидят, и что-то кажется мне, что никуда и не слезут уже никогда...
Субъективные понятия "хороший" и "плохой" применимы только к конкретной ситуации.
Язык это всего лишь инструмент. Если он тебе не нравится, не выбирай его, выбирай то, что нравится.Кому какое дело какими кистями и красками пользуется художник?
Ты когда нибудь слышал, чтобы кто-нибудь говорил что-то подобное: "Это картина не красивая, потому что художник использовал не ту кисть"?
Ну, как по мне так он не очень нужен. В Docker Swarm Node/Kubernetes для проксирования апи, ИМХО, куда лучше работает traefik (из коробки интеграция со всеми популярными kv-хранилищами и каталогами service discovery), а для раздачи статики - проще использовать чистый nginx на выделенных серверах - его все админы знают, да и вообще старый конь борозды не испортит. Где тут место сабжа, лично я не очень понимаю.
Эта Docker Swarm глючная до невозможности, как и всё, что относится к этим всем "новомодным". А nginx-стабильнейшая и жутко производительная софтина (особенно на фоне всего этого новомодного шлака). Если сабж будет таким же как и сам nginx-будем непременно юзать его, вместо всех этих "новомодных"
1. nginx всего на 5 лет старше ноды, они почти ровесники.
2. nginx не всегда выигрывает по производительность у той же ноды.
Приложением льда ко лбу им надо заниматься.
А программы пишут на C/C++.
Так и новость про то, что вышла новая версия _программы_ для запуска _приложений_.
Вот объясните мне плиз, люди добрые. В докладе (https://www.youtube.com/watch?v=GK6xAOVRTcg) сказано, что nginx взаимодействует с unit через разделяемую память минуя сетевой стек. А в документации сказано, что обращаться нужно к unit нужно через сокет, типа:upstream php_upstream {
server 127.0.0.1:8090;
}Это как понимать? Принцип обращения через разделяемую память еще не реализован?
Речь идет о взаимодействии между процессом роутера, который асинхронно принимает и обрабатывает клиентские соединения и процессами приложений. Всё это части Unit'а и об nginx речи не идет.В документации в разделе "Integration with NGINX" рассказано о том, как можно запроксировать Unit, при желании. Но по мере обрастания возможностями, необходимости в этом будет всё меньше и меньше.
Валентин, спасибо как за ответ, так и за интересный доклад.Все же остается не понятным то, чем Unit отличается от любого другого сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. Тот же uWSGI так же используется разделяемую память между мастер процессом и воркерами.
> Валентин, спасибо как за ответ, так и за интересный доклад.
> Все же остается не понятным то, чем Unit отличается от любого другого
> сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx.
> Тот же uWSGI так же используется разделяемую память между мастер процессом
> и воркерами.Насколько я знаю, разделяемая память там другим целям служит, а master процесс, также как и в nginx, не занимается обработкой запросов. В Unit-е есть свой такой мастер-процесс для порождения новых процессов, открытия слушающих сокетов и лог-файлов.
Основное отличие в том, что Unit с самого начала проектируется чтобы смотреть наружу, в интернет, а не прятаться за реверсивным прокси. Там уже, условно говоря, есть свой, встроенный nginx - процесс роутера. Поэтому он прекрасно держит нагрузку в то время, когда uwsgi сливается: https://itnext.io/performance-comparison-between-nginx-unit-...
Сама внутренняя архитектура у Unit'а такова, что ему concurrency абсолютно до лампочки, 10 клиентов к нему придут с запросами или миллион - он будет продолжать обрабатывать запросы не снижая эффективности.Вот даже глядя на график в статье по ссылке, не трудно представить себе такую ситуацию: стоит у вас один или несколько проксирующих nginx-ов, раздают трафик на несколько uwsgi. Всё хорошо, все стабильно, каждый uwsgi-сервер обрабатывает по нескольку тысяч запросов в секунду не захлебываясь. А тут черная пятница, распродажи, маркетологи запустили очень успешную рекламную кампанию и на ваши сервера прибежали клиенты в количествах больших, чем вы предполагали. Всех этих клиентов nginx благополучно запроксировал на uwsgi и тот начал от такой конкурентности загибаться. Вместо тысяч запросов в секунду, производительность каждого сервера упала до десятков. Сайт практически лежит, вы добавляете новые сервера, а они продолжают загибаться. Менеджмент пьет валокордин и подсчитывает убытки.
Теперь же другая картина и у вас не uwsgi, а Unit. Навалило клиентов, а каждый сервер с Unit'ом, как молотил 10 тыс запросов в секунду в пике так и продолжает. Видя в мониторинге, что количество запросов в секунду уперлось в потолок ваших мощностей, вы добавляете ещё несколько серверов с Unit'ом и те успешно берут на себя избыток нагрузки. Клиенты практически даже не замечают каких-то лагов.
И тут в палату входят санитары \ И тут ты просыпаешься:-)
> как молотил 10 тыс запросов в секунду в пике так и продолжаетТо есть остальные он просто дропает?
Орригинальное решение.
Ничего не дропается. Просто плавно растут задержки, запросы ждут в очереди.
Валентин, отличный рассказ.Ниже я вам задал вопрос про условия проведения тестов, на которые вы дали ссылку.
У меня закрались сомнения, что тесты проводились в максимально производильной конфигурации.
Ответьте, пожалуйста.
Спасибо.
>https://itnext.io/performance-comparison-between-nginx-unit-...-Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?
> Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?По горизонтальной оси - количество установленных соединений, которое использовалось для одновременной отправки запросов, а по вертикальной количество запросов в секунду, которое при этом сервер обрабатывал.
Там есть графики для 10 тысяч запросов и для 100 тысяч.
Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.
Валентин, спасибо за столь детальное объяснение. Теперь все понятно. Жать что пока что мало документации о внутреннем устройстве Unit и о технологических подходах который применялись при создании его.
Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером было:1) через стандартный сокет, не через unix сокет?
2) через HTTP протокол, а не бинарный "uwsgi".Ведь отсюда вытекает, что тестирование uWSGI было проведено в самой непроипроизводительной конфигурации. И тогда, возможно, мы бы не увидели на графике такого "разгрома".
Если эти 2 условия не были соблюдены, то врятли этим тесты можно воспринимать всерьез.
Вот нагуглил:
https://www.digitalocean.com/community/tutorials/how-to-serv...Instead of using a network port, since all of the components are operating on a single server, we can use a Unix socket. This is more secure and offers better performance. This socket will not use HTTP, but instead will implement uWSGI's uwsgi protocol, which is a fast binary protocol for designed for communicating with other servers. Nginx can natively proxy using the uwsgi protocol, so this is our best choice.
Когда используется TCP сокет взамест Unix сокету, то используется HTTP, а не бинарный протокол.
Читай - непроизводительный сокет + непроизводительный протокол.Соответственно, как я писал выше, тесты можно считать недействительными если использовался TCP сокет. Более странно, раз уж вы занимаетесь такими вещами, то не можете не знать, как взаимодействовать с uWSGI наиболее производительным способом. Если вы знаете это, то тогда почему этот способ не использовался?
> Вот нагуглил:
> https://www.digitalocean.com/community/tutorials/how-to-serv...[..]
> Соответственно, как я писал выше, тесты можно считать недействительными если использовался
> TCP сокет. Более странно, раз уж вы занимаетесь такими вещами, то
> не можете не знать, как взаимодействовать с uWSGI наиболее производительным способом.
> Если вы знаете это, то тогда почему этот способ не использовался?Отмечу несколько моментов:
1. Ни я, ни кто-либо из моих коллег не имеет к статье и её автору никакого отношения. Насколько я понимаю, человек каждый день в своей практике использует uWSGI, а тут увидел Unit и решил его сравнить.
2. Протокол uwsgi и unix-сокеты между собой не связаны. Взаимодействие с использованием uwsgi протокола nginx умеет как поверх TCP, так и поверх unix-сокетов.
3. Поскольку в данном тесте nginx вообще отсутствовал, то говорить о том, как и по какому протоколу он с ним общался - лишено смысла. Браузеры на сервер приходят не по unix-сокету и не по uwsgi протоколу.
4. Даже если бы nginx использовался, то ни uwsgi, ни unix-сокеты никак не повлияли бы на ситуацию. TCP через loopback интерфейс - это весьма эффективный механизм, мало уступающий unix-сокетам. А бинарного в протоколе uwsgi - только длины имен и значений CGI-переменных (которые сами по себе по прежнему суть текстовые заголовки) и за счет этого он всего пару процентов может выиграть у HTTP. Но вообще на сам парсинг во всей обработке запроса приходится меньше процента - это ничтожная по ресурсам операция на фоне работы виртуальной машины cpython, так что разница была бы практически неизмерима.
5. Именно потому, что мы прекрасно понимаем и знаем досконально как всё это работает, мы видим огромный ещё нераскрытый потенциал сделать масштабируемый сервер, который лучше других держит высокие нагрузки. И если бы это было не так, то мы бы сейчас не писали Unit, а занимались более перспективными задачами. И даже данный бенчмарк не показатель, а лишь отправная точка. Ещё не всё даже реализовано так, как хотелось бы.
Спасибо за ответ.Я не говорил, что статья по ссылке к вам как-то относится.
Из ваших слов вытекает, что при тесте использовался HTTP через TCP.
>> ни uwsgi, ни unix-сокеты никак не повлияли бы на ситуацию. TCP через loopback интерфейс
>> это ничтожная по ресурсам операция на фоне работы виртуальной машины cpythonВы сами себе противоречите, говоря что Unit дает преимущество, тк. там нет узкого места при взаимодействии с ВМ. И тут же пишите, что ВМ узкое место и юникс сокеты с бинарным протоколом ничего не решат, тк даже loopback интерфейс прекрасен и не является узким местом.
Я вам указываю, лишь на то, что unix socket + бинарный протокол даст больше производительности и слабо верю в те сферические 2%. Может быть все же 20%?
1) В Unix сокетах нет буферизации и логики роутинга. Я находил в инете цифры 10-20% большей произв-ти по сравнению с TCP.
2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP.Так что давайте остановимся на цифре +20% и "разгром", следовательно, отменяется.
Вы же понимаете, что странно устраивать тест на производительность и допустить такую оплошность.
Именно поэтому нужно задействовать unix socket + бинарный протокол и провести тесты заново.
Тогда не будет никаких сомнений в "разгроме".
[..]
> 1) В Unix сокетах нет буферизации и логики роутинга. Я находил в
> инете цифры 10-20% большей произв-ти по сравнению с TCP.
> 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый
> протокол такой как HTTP.Если вам действительно интересны грамотные тесты TCP vs. Unix domain socket, то смотрите:
https://www.cl.cam.ac.uk/research/srg/netos/projects/ipc-ben...И ещё раз повторяю, как человек, знающий протокол uwsgi до каждого битика - оне НЕ бинарный. Это текстовый протокол с бинарными длинами строк. Это примерно как C-like строки, против Pascal-like строк.
Спорить с аргументами основанными на "что-то где-то находил в интернете" мне неинтересно. Это бесплатно, это open-source, так что каждый может скачать и убедиться. Зачем мне что-то доказывать, если есть продукт, который говорит сам за себя.
Успехов!
> 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP.Адекватному программисту ясно, что это сильно зависит от данных. Если данные состоят в основном из чисел, то разница будет заметной. Если же данные большей частью состоят из строк да еще и без экранирования, то разница почти нулевая.
Вот копипаста от разрабов uWSGi:Why not simply use HTTP as the protocol?
A good question with a simple answer: HTTP parsing is slow, really slow. Why should we do a complex task twice? The web server has already parsed the request! The uwsgi protocol is very simple to parse for a machine, while HTTP is very easy to parse for a human. As soon as humans are being used as servers, we will abandon the uwsgi protocol in favor of the HTTP protocol. All this said, you can use uWSGI via Native HTTP support, FastCGI, ZeroMQ and other protocols as well.
Не тестировал производительность, но у меня нет привычки держать себя умнее всех и полагать, что вокруг одни идиоты. Не вижу повода не доверять их мнению.
Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков и их значений, то есть это парсинг вслепую. В то же самое время можно задавать длины полей, и парсинг будет происходить четко пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или нет, не имеет значения.
> Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков
> и их значений, то есть это парсинг вслепую. В то же
> самое время можно задавать длины полей, и парсинг будет происходить четко
> пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это
> типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или
> нет, не имеет значения.1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам.
2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать.Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует.
В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую.
Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.
Также в тестах, насколько я понял, нет uSWGI c Go.
А то я скорее вижу там как в лоб сравнивается производительность Go с Python.
Это добавляет еще большей сферичности вашим тестам.
Итого нужны тесты:1) Unit + Go vs Unix Socket + binary uswgi + Go
2) Unit + Python vs Unix Socket + binary uswgi + PythonТогда это будет не маркетинговый тест.
> Итого нужны тесты:
> 1) Unit + Go vs Unix Socket + binary uswgi + Go
> 2) Unit + Python vs Unix Socket + binary uswgi + Python
> Тогда это будет не маркетинговый тест.Уточните, а кто должен общаться с uWSGI по его "binary" протоколу? Клиенты этого делать не умеют.
Очевидно, что Nginx.
> Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером
> было:В данной статье nginx вообще нет.
Все-таки мне кажется, что не будет это востребовано. Толстосерверы не в моде