<?xml version="1.0" encoding="koi8-r"?>
<rss version="0.91">
<channel>
    <title>OpenForum RSS: Выпуск сервера приложений NGINX Unit 1.6</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html</link>
    <description>Представлен (http://mailman.nginx.org/pipermail/unit/2018-November/000083.html) выпуск сервера приложений 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.ru/opennews/art.shtml?num=48434) первого выпуска. &lt;br&gt;&lt;br&gt;&lt;br&gt;Основное внимание при подготовке новой версии было сосредоточено на улучшении работы модуля поддержки платформы Node.js и обеспечении его совместимости с различными приложениями. Сборочная команда &quot;make install&quot; теперь устанавливает модуль к Node.js, </description>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (user455)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#66</link>
    <pubDate>Mon, 26 Nov 2018 13:57:37 GMT</pubDate>
    <description>а пайтоновские фреймворки сами как веб сервер не умеют запускаться? &lt;br&gt;&lt;br&gt;зачем там нужен нгинкс в каждом контейнере? &lt;br&gt;&lt;br&gt;нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет? &lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Valentin V. Bartenev)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#65</link>
    <pubDate>Tue, 20 Nov 2018 10:24:48 GMT</pubDate>
    <description>&amp;gt; Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков &lt;br&gt;&amp;gt; и их значений, то есть это парсинг вслепую. В то же &lt;br&gt;&amp;gt; самое время можно задавать длины полей, и парсинг будет происходить четко &lt;br&gt;&amp;gt; пошагаво по &quot;меткам&quot;(смещение) , а не сканя каждый байт. Т.е. это &lt;br&gt;&amp;gt; типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или &lt;br&gt;&amp;gt; нет, не имеет значения.&lt;br&gt;&lt;br&gt;1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам.&lt;br&gt;2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать.&lt;br&gt;&lt;br&gt;Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует.&lt;br&gt;&lt;br&gt;В любом</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Ку)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#64</link>
    <pubDate>Tue, 20 Nov 2018 08:02:59 GMT</pubDate>
    <description>Очевидно, что Nginx.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Ку)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#63</link>
    <pubDate>Tue, 20 Nov 2018 08:00:08 GMT</pubDate>
    <description>Вот копипаста от разрабов uWSGi:&lt;br&gt;&lt;br&gt;Why not simply use HTTP as the protocol?&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;Не тестировал производительность, но у меня нет привычки держать себя умнее всех и полагать, что вокруг одни идиоты. Не вижу повода не доверять их мнению.&lt;br&gt;&lt;br&gt;Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков и их значений, то есть это парсинг вслепую. В то же самое время можно задавать длины полей, и парсинг будет происходить четко пошагаво по &quot;меткам&quot;(смещение) , а не сканя каждый байт. Т.е. это типичная (де)сериализа</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (angra)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#62</link>
    <pubDate>Mon, 19 Nov 2018 23:15:35 GMT</pubDate>
    <description>&amp;gt; 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP.&lt;br&gt;&lt;br&gt;Адекватному программисту ясно, что это сильно зависит от данных. Если данные состоят в основном из чисел, то разница будет заметной. Если же данные большей частью состоят из строк да еще и без экранирования, то разница почти нулевая. &lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Valentin V. Bartenev)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#61</link>
    <pubDate>Mon, 19 Nov 2018 12:29:34 GMT</pubDate>
    <description>&amp;gt; Итого нужны тесты:&lt;br&gt;&amp;gt; 1) Unit + Go vs Unix Socket + binary uswgi + Go &lt;br&gt;&amp;gt; 2) Unit + Python vs Unix Socket + binary uswgi + Python &lt;br&gt;&amp;gt; Тогда это будет не маркетинговый тест.&lt;br&gt;&lt;br&gt;Уточните, а кто должен общаться с uWSGI по его &quot;binary&quot; протоколу? Клиенты этого делать не умеют.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Valentin V. Bartenev)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#60</link>
    <pubDate>Mon, 19 Nov 2018 12:27:30 GMT</pubDate>
    <description>&#091;..&#093;&lt;br&gt;&amp;gt; 1) В Unix сокетах нет буферизации и логики роутинга. Я находил в &lt;br&gt;&amp;gt; инете цифры 10-20&#037; большей произв-ти по сравнению с TCP.&lt;br&gt;&amp;gt; 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый &lt;br&gt;&amp;gt; протокол такой как HTTP.&lt;br&gt;&lt;br&gt;Если вам действительно интересны грамотные тесты TCP vs. Unix domain socket, то смотрите:&lt;br&gt;https://www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/details/tmplg7xfX.html&lt;br&gt;&lt;br&gt;И ещё раз повторяю, как человек, знающий протокол uwsgi до каждого битика - оне НЕ бинарный. Это текстовый протокол с бинарными длинами строк. Это примерно как C-like строки, против Pascal-like строк.&lt;br&gt;&lt;br&gt;Спорить с аргументами основанными на &quot;что-то где-то находил в интернете&quot; мне неинтересно. Это бесплатно, это open-source, так что каждый может скачать и убедиться. Зачем мне что-то доказывать, если есть продукт, который говорит сам за себя.&lt;br&gt; &lt;br&gt;Успехов!&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Ку)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#59</link>
    <pubDate>Mon, 19 Nov 2018 09:03:37 GMT</pubDate>
    <description>Итого нужны тесты:&lt;br&gt;&lt;br&gt;1) Unit + Go vs Unix Socket + binary uswgi + Go&lt;br&gt;2) Unit + Python vs Unix Socket + binary uswgi + Python&lt;br&gt;&lt;br&gt;Тогда это будет не маркетинговый тест.&lt;br&gt;</description>
</item>

<item>
    <title>Выпуск сервера приложений NGINX Unit 1.6 (Ку)</title>
    <link>https://opennet.me/openforum/vsluhforumID3/115841.html#58</link>
    <pubDate>Mon, 19 Nov 2018 08:49:44 GMT</pubDate>
    <description>Также в тестах, насколько я понял, нет uSWGI c Go.&lt;br&gt;А то я скорее вижу там как в лоб сравнивается производительность Go с Python.&lt;br&gt;Это добавляет еще большей сферичности вашим тестам.&lt;br&gt;&lt;br&gt;</description>
</item>

</channel>
</rss>
