The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

16.11.2018 08:23  Выпуск сервера приложений NGINX Unit 1.6

Представлен выпуск сервера приложений NGINX Unit 1.6, в рамках которого развивается решение для обеспечения запуска web-приложений на различных языках программирования (Python, PHP, Perl, Ruby, Go и JavaScript/Node.js). Под управлением NGINX Unit может одновременно выполняться несколько приложений на разных языках программирования, параметры запуска которых можно изменять динамически без необходимости правки файлов конфигурации и перезапуска. Код написан на языке Си и распространяется под лицензией Apache 2.0. С особенностями NGINX Unit можно познакомиться в анонсе первого выпуска.

Основное внимание при подготовке новой версии было сосредоточено на улучшении работы модуля поддержки платформы Node.js и обеспечении его совместимости с различными приложениями. Сборочная команда "make install" теперь устанавливает модуль к Node.js, если он отмечен для сборки. В скрипт "configure" также добавлена опция "--local" для локальной установки модуля Node.js.

  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Обновление nginx 1.14.1 и 1.15.6 с устранением трёх уязвимостей
  3. OpenNews: Релиз njs 0.2.5, интерпретатора JavaScript от NGINX
  4. OpenNews: Выпуск сервера приложений NGINX Unit 1.5 с поддержкой Node.js
  5. OpenNews: Первый стабильный релиз сервера приложений NGINX Unit
Лицензия: CC-BY
Тип: Программы
Ключевые слова: nginx, unit
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, max (??), 08:44, 16/11/2018 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Господа,

    Кто использовал? СтОит, не стОит? Поделитесь пожалуйста впечатлениями. )

     
     
  • 2.2, Eduard (??), 09:03, 16/11/2018 [^] [ответить]    [к модератору]
  • –4 +/
    Сейчас в kubernetes приходится делать nginx sidecar в pod, чтобы проксировать в uwsgi приложение.
    С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.

    Однозначно стоит.

     
     
  • 3.28, Аноним (28), 20:12, 16/11/2018 [^] [ответить]     [к модератору]
  • +1 +/
    Во-первых, у приложения интерфейс не uwsgi, а WSGI usgi 8212 это одна из реа... весь текст скрыт [показать]
     
  • 3.31, Аноним (31), 21:41, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    >С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.

    Вообще-то uwsgi может выступать в качестве веб-сервера. По сему в связке nginx + uwsgi, nginx лишний.

     
     
  • 4.33, Аноним (33), 22:04, 16/11/2018 [^] [ответить]    [к модератору]  
  • +3 +/
    Оу, у нас иксперды в треде
     
     
  • 5.43, Аноним (43), 02:19, 17/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Подселять по энжиниксу к каждому экземпляру uwsgi действительно излине Большую ... весь текст скрыт [показать]
     
  • 3.66, user455 (?), 16:57, 26/11/2018 [^] [ответить]    [к модератору]  
  • +/
    а пайтоновские фреймворки сами как веб сервер не умеют запускаться?

    зачем там нужен нгинкс в каждом контейнере?

    нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет?

     
  • 2.3, Аноним (3), 09:07, 16/11/2018 [^] [ответить]     [к модератору]  
  • –9 +/
    Так посмотри на список поддерживаемых языков платформ Пихон, пых, устаревший пе... весь текст скрыт [показать]
     
     
  • 3.4, ыы (?), 09:12, 16/11/2018 [^] [ответить]    [к модератору]  
  • +13 +/
    > Python, PHP, Perl, Ruby, Go и JavaScript/Node.js

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

    Да кому она нужна ваша дырявая и сдыхающая жаба?

     
     
  • 4.5, Аноним (3), 09:56, 16/11/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    А вот и любители смузи-динамических языков подъехали. Ну как там, электрон оперативку жрет?
     
  • 4.9, Аноним (9), 12:42, 16/11/2018 [^] [ответить]     [к модератору]  
  • –2 +/
    Под Явой весь корпоративный сектор, более того, на Яву меняют, тихо но уверенно,... весь текст скрыт [показать]
     
     
  • 5.10, Аноним (10), 12:50, 16/11/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    На яве пишут бизнес-логику, а сам бэкенд на других языках Тот же paypal сменил ... весь текст скрыт [показать]
     
     
  • 6.11, Аноним (9), 13:26, 16/11/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Дя-дя, букенд там у него на других языках. Вся ява там крутится на серверах приложений, которые в шкафах от оракела или ибма исполняются, а не на "других языках".
     
     
  • 7.12, Аноним (9), 13:31, 16/11/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    И в качестве букенда стоят rdbms-ы. И никаких "других языков" типа C++ и, тем более, всяких смузи-электронов, там нет и в помине.
     
  • 6.13, ананим.orig (?), 13:39, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    s бэкенд фронтэд ... весь текст скрыт [показать]
     
     
  • 7.14, Аноним (10), 13:53, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Не, фронтенд там nginx обычно (я не про браузер-сайд).
     
     
  • 8.15, powershell (ok), 14:05, 16/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Прошу заметить, что в обсуждаемых архитектурах может быть несколько пар фронтенд... весь текст скрыт [показать]
     
  • 5.24, Аноним (24), 18:04, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Это ты хорошо яву с коболом сравнил Звиняй, для реального мира навозная яма в к... весь текст скрыт [показать]
     
     
  • 6.29, Аноним (9), 21:24, 16/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    >> Реальный мир выбирает работающие технологии

    Чуть-чуть не проговорился про docker, вот смешно было бы, в контексте разговора про "работающие технологии".

     
  • 6.30, Аноним (9), 21:27, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Эти работающие технологии меняются раз в пять лет А Кобол с Явой как были так... весь текст скрыт [показать]
     
     
  • 7.39, ананим.orig (?), 23:06, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > они прокручивают самые ответственные системы мира этого.

    Не поэтому ли ли он в опе? :D

     
     
  • 8.42, Аноним (9), 00:11, 17/11/2018 [^] [ответить]     [к модератору]  
  • –1 +/
    По всем аспектам, прежде всего по количеству бабла, которое крутится в индустрии... весь текст скрыт [показать]
     
  • 8.50, Ку (?), 15:59, 18/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Тут нужно просто понимать инфантильную подростковую психологию, не более Вопрос... весь текст скрыт [показать]
     
  • 3.16, Valentin V. Bartenev (?), 14:13, 16/11/2018 [^] [ответить]     [к модератору]  
  • +3 +/
    Поддержка Java активно разрабатывается https github com mar0x unit tree java ... весь текст скрыт [показать]
     
     
  • 4.18, Аноним (18), 15:02, 16/11/2018 [^] [ответить]     [к модератору]  
  • –1 +/
    Спасибо, это хорошая новость А можно поинтересоваться, почему начали именно с я... весь текст скрыт [показать]
     
     
  • 5.21, Аноним (21), 16:00, 16/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Потому что там, где повсеместно используется ява, быстро внедрять nginx unit все равно не начнут в силу консерватизма.
     
  • 5.22, KonstantinB (ok), 16:26, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Я не знаю, но могу предположить Интеграция того же php элементарна - пишется св... весь текст скрыт [показать]
     
  • 5.23, Valentin V. Bartenev (?), 17:43, 16/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Это семейство языков имеет простой API для веб-приложений и легко интегрируется ... весь текст скрыт [показать]
     
  • 5.34, vitalif (ok), 22:27, 16/11/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    Чего там хорошо в этой яве? До сих пор на аппсерверах все сидят, и что-то кажется мне, что никуда и не слезут уже никогда...
     
     
  • 6.51, Ку (?), 16:22, 18/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Субъективные понятия хороший и плохой применимы только к конкретной ситуации... весь текст скрыт [показать]
     
  • 2.19, jOKer (ok), 15:12, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Ну, как по мне так он не очень нужен В Docker Swarm Node Kubernetes для проксир... весь текст скрыт [показать]
     
     
  • 3.20, Аноним (9), 15:35, 16/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Эта Docker Swarm глючная до невозможности, как и всё, что относится к этим всем ... весь текст скрыт [показать]
     
     
  • 4.40, Аноним (10), 23:10, 16/11/2018 [^] [ответить]    [к модератору]  
  • –3 +/
    1. nginx всего на 5 лет старше ноды, они почти ровесники.
    2. nginx не всегда выигрывает по производительность у той же ноды.
     
  • 1.17, InuYasha (?), 14:25, 16/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Приложением льда ко лбу им надо заниматься.
    А программы пишут на C/C++.
     
     
  • 2.27, НяшМяш (ok), 20:02, 16/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Так и новость про то, что вышла новая версия _программы_ для запуска _приложений_.
     
  • 1.32, Аноним (31), 22:03, 16/11/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +2 +/
    Вот объясните мне плиз, люди добрые В докладе https www youtube com watch v ... весь текст скрыт [показать]
     
     
  • 2.36, Valentin V. Bartenev (?), 22:33, 16/11/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    Речь идет о взаимодействии между процессом роутера, который асинхронно принимает... весь текст скрыт [показать]
     
     
  • 3.37, Аноним (31), 22:45, 16/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Валентин, спасибо как за ответ, так и за интересный доклад Все же остается не п... весь текст скрыт [показать]
     
     
  • 4.38, Valentin V. Bartenev (?), 23:03, 16/11/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Насколько я знаю, разделяемая память там другим целям служит, а master процесс, ... весь текст скрыт [показать]
     
     
  • 5.41, Valentin V. Bartenev (?), 23:38, 16/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Сама внутренняя архитектура у Unit а такова, что ему concurrency абсолютно до ла... весь текст скрыт [показать]
     
     
  • 6.44, _ (??), 04:25, 17/11/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    И тут в палату входят санитары \ И тут ты просыпаешься

    :-)

     
  • 6.45, ыы (?), 09:16, 17/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > как молотил 10 тыс запросов в секунду в пике так и продолжает

    То есть остальные он просто дропает?
    Орригинальное решение.

     
     
  • 7.47, Valentin V. Bartenev (?), 15:50, 17/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Ничего не дропается. Просто плавно растут задержки, запросы ждут в очереди.
     
  • 6.54, Ку (?), 01:02, 19/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Валентин, отличный рассказ Ниже я вам задал вопрос про условия проведения тесто... весь текст скрыт [показать]
     
  • 5.46, ыы (?), 09:28, 17/11/2018 [^] [ответить]    [к модератору]  
  • +/
    >https://itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-

    Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?

     
     
  • 6.48, Valentin V. Bartenev (?), 15:58, 17/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?

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

    Там есть графики для 10 тысяч запросов и для 100 тысяч.

    Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.

     
     
  • 7.49, Аноним (31), 16:59, 17/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Валентин, спасибо за столь детальное объяснение Теперь все понятно Жать что по... весь текст скрыт [показать]
     
  • 7.52, Ку (?), 00:14, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером было:

    1) через стандартный сокет, не через unix сокет?
    2) через HTTP протокол, а не бинарный "uwsgi".

    Ведь отсюда вытекает, что тестирование uWSGI было проведено в самой непроипроизводительной конфигурации. И тогда, возможно, мы бы не увидели на графике такого "разгрома".

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

     
     
  • 8.53, Ку (?), 00:48, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Вот нагуглил:
    https://www.digitalocean.com/community/tutorials/how-to-serve-django-applicati

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

     
     
  • 9.56, Valentin V. Bartenev (?), 05:21, 19/11/2018 [^] [ответить]     [к модератору]  
  • +/
    Отмечу несколько моментов 1 Ни я, ни кто-либо из моих коллег не имеет к с... весь текст скрыт [показать]
     
     
  • 10.57, Ку (?), 11:18, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Спасибо за ответ.

    Я не говорил, что статья по ссылке к вам как-то относится.

    Из ваших слов вытекает, что при тесте использовался HTTP через TCP.

    >> ни uwsgi, ни unix-сокеты никак не повлияли бы на ситуацию. TCP через loopback интерфейс
    >> это ничтожная по ресурсам операция на фоне работы виртуальной машины cpython

    Вы сами себе противоречите, говоря что Unit дает преимущество, тк. там нет узкого места при взаимодействии с ВМ. И тут же пишите, что ВМ узкое место и юникс сокеты с бинарным протоколом ничего не решат, тк даже loopback интерфейс прекрасен и не является узким местом.

    Я вам указываю, лишь на то, что unix socket + бинарный протокол даст больше производительности и слабо верю в те сферические 2%. Может быть все же 20%?

    1) В Unix сокетах нет буферизации и логики роутинга. Я находил в инете цифры 10-20% большей произв-ти по сравнению с TCP.
    2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP.

    Так что давайте остановимся на цифре +20% и "разгром", следовательно, отменяется.

    Вы же понимаете, что странно устраивать тест на производительность и допустить такую оплошность.
    Именно поэтому нужно задействовать unix socket + бинарный протокол и провести тесты заново.
    Тогда не будет никаких сомнений в "разгроме".

     
     
  • 11.60, Valentin V. Bartenev (?), 15:27, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    [..]
    > 1) В Unix сокетах нет буферизации и логики роутинга. Я находил в
    > инете цифры 10-20% большей произв-ти по сравнению с TCP.
    > 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый
    > протокол такой как HTTP.

    Если вам действительно интересны грамотные тесты TCP vs. Unix domain socket, то смотрите:
    https://www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/details/tmplg7x

    И ещё раз повторяю, как человек, знающий протокол uwsgi до каждого битика - оне НЕ бинарный. Это текстовый протокол с бинарными длинами строк. Это примерно как C-like строки, против Pascal-like строк.

    Спорить с аргументами основанными на "что-то где-то находил в интернете" мне неинтересно. Это бесплатно, это open-source, так что каждый может скачать и убедиться. Зачем мне что-то доказывать, если есть продукт, который говорит сам за себя.

    Успехов!

     
  • 11.62, angra (ok), 02:15, 20/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP.

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

     
     
  • 12.63, Ку (?), 11:00, 20/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Вот копипаста от разрабов 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 вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков и их значений, то есть это парсинг вслепую. В то же самое время можно задавать длины полей, и парсинг будет происходить четко пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или нет, не имеет значения.

     
     
  • 13.65, Valentin V. Bartenev (?), 13:24, 20/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков
    > и их значений, то есть это парсинг вслепую. В то же
    > самое время можно задавать длины полей, и парсинг будет происходить четко
    > пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это
    > типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или
    > нет, не имеет значения.

    1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам.
    2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать.

    Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует.

    В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую.

    Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.

     
  • 10.58, Ку (?), 11:49, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Также в тестах, насколько я понял, нет uSWGI c Go.
    А то я скорее вижу там как в лоб сравнивается производительность Go с Python.
    Это добавляет еще большей сферичности вашим тестам.

     
  • 10.59, Ку (?), 12:03, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Итого нужны тесты:

    1) Unit + Go vs Unix Socket + binary uswgi + Go
    2) Unit + Python vs Unix Socket + binary uswgi + Python

    Тогда это будет не маркетинговый тест.

     
     
  • 11.61, Valentin V. Bartenev (?), 15:29, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > Итого нужны тесты:
    > 1) Unit + Go vs Unix Socket + binary uswgi + Go
    > 2) Unit + Python vs Unix Socket + binary uswgi + Python
    > Тогда это будет не маркетинговый тест.

    Уточните, а кто должен общаться с uWSGI по его "binary" протоколу? Клиенты этого делать не умеют.

     
     
  • 12.64, Ку (?), 11:02, 20/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Очевидно, что Nginx.
     
  • 8.55, Valentin V. Bartenev (?), 04:36, 19/11/2018 [^] [ответить]    [к модератору]  
  • +/
    > Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером
    > было:

    В данной статье nginx вообще нет.

     
  • 1.35, vitalif (ok), 22:28, 16/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Все-таки мне кажется, что не будет это востребовано. Толстосерверы не в моде
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor