Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск сервера приложений NGINX Unit 1.6"	+/–
Сообщение от opennews (??), 16-Ноя-18, 08:44
Представлен (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
Сообщение от max (??), 16-Ноя-18, 08:44
Господа, Кто использовал? СтОит, не стОит? Поделитесь пожалуйста впечатлениями. )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Выпуск сервера приложений NGINX Unit 1.6"	–4 +/–
	Сообщение от Eduard (??), 16-Ноя-18, 09:03
	Сейчас в kubernetes приходится делать nginx sidecar в pod, чтобы проксировать в uwsgi приложение. С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit. Однозначно стоит.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	28. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (28), 16-Ноя-18, 20:12
	Во-первых, у приложения интерфейс не uwsgi, а WSGI. usgi — это одна из реализаций wsgi application server-а и одноименный бинарный протокол, придуманный авторами uswgi. Во-вторых, большинство wsgi app-серверов (включая uwsgi) умеют отвечать по http.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	31. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Аноним (31), 16-Ноя-18, 21:41
	>С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit. Вообще-то uwsgi может выступать в качестве веб-сервера. По сему в связке nginx + uwsgi, nginx лишний.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	33. "Выпуск сервера приложений NGINX Unit 1.6"	+3 +/–
	Сообщение от Аноним (33), 16-Ноя-18, 22:04
	Оу, у нас иксперды в треде
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	43. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (43), 17-Ноя-18, 02:19
	Подселять по энжиниксу к каждому экземпляру uwsgi действительно излине. Большую часть того, что бэкендеры обычно хотят от творения Сысоева, успешно можно сделать средствами uwsgi (рерайты, редиректы, работа с заголовками итд). Остальное уже спокойно делается на тех энжиниксах, которые балансируют нагрузку между бэкендами (тем более, что у любителя энжиникса в сайдкарах по определению кубернетес и, скорее всего, используются ингрессы с энжиниксом)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	66. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от user455 (?), 26-Ноя-18, 16:57
	а пайтоновские фреймворки сами как веб сервер не умеют запускаться? зачем там нужен нгинкс в каждом контейнере? нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	3. "Выпуск сервера приложений NGINX Unit 1.6"	–9 +/–
	Сообщение от Аноним (3), 16-Ноя-18, 09:07
	Так посмотри на список поддерживаемых языков/платформ: > Python, PHP, Perl, Ruby, Go и JavaScript/Node.js Пихон, пых, устаревший перл, нескучный руби, го-секта и вспомнити лефтпад. Я бы дождался поддержки Java для начала. С ее появлением уже может пойти речь о чем-то взрослом, серьезном.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Выпуск сервера приложений NGINX Unit 1.6"	+13 +/–
	Сообщение от ыы (?), 16-Ноя-18, 09:12
	> Python, PHP, Perl, Ruby, Go и JavaScript/Node.js Мэйнстрим,  суперпопулярный, стабильная классика, популярный с отдельных кругах, активно развиваемый суперкорпорацией, суперпопулярный среди молодежи. Да кому она нужна ваша дырявая и сдыхающая жаба?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Выпуск сервера приложений NGINX Unit 1.6"	–3 +/–
	Сообщение от Аноним (3), 16-Ноя-18, 09:56
	А вот и любители смузи-динамических языков подъехали. Ну как там, электрон оперативку жрет?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Выпуск сервера приложений NGINX Unit 1.6"	–2 +/–
	Сообщение от Аноним (9), 16-Ноя-18, 12:42
	Под Явой весь корпоративный сектор, более того, на Яву меняют, тихо но уверенно, всё, что написано на Коболе, а это вся фин.индустрия мира. Но в шалашах по клепанию всяких свистоперделок для вебни об этом не в курсе, у них там полный смузи электрон по самые гланды.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "Выпуск сервера приложений NGINX Unit 1.6"	+2 +/–
	Сообщение от Аноним (10), 16-Ноя-18, 12:50
	На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от Аноним (9), 16-Ноя-18, 13:26
	Дя-дя, букенд там у него на других языках. Вся ява там крутится на серверах приложений, которые в шкафах от оракела или ибма исполняются, а не на "других языках".
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от Аноним (9), 16-Ноя-18, 13:31
	И в качестве букенда стоят rdbms-ы. И никаких "других языков" типа C++ и, тем более, всяких смузи-электронов, там нет и в помине.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от ананим.orig (?), 16-Ноя-18, 13:39
	> На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься #s/бэкенд/фронтэд/
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	14. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Аноним (10), 16-Ноя-18, 13:53
	Не, фронтенд там nginx обычно (я не про браузер-сайд).
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от powershell (ok), 16-Ноя-18, 14:05
	Прошу заметить, что в обсуждаемых архитектурах может быть несколько пар фронтенд/бэкенд, все зависит от уровня абстракции и вероятно вы доказываете одну точку зрения оперируя информацией о разных слоях одной архитектуры.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Аноним (24), 16-Ноя-18, 18:04
	Это ты хорошо яву с коболом сравнил. Звиняй, для реального мира навозная яма в которой копошатся банкиры и финансисты со своими коболами, жавами, 1C и оракалами совершенно побоку, тем более как ориентир для выбора технологий. Это не взрослость, это просто узкоспецифичная вонючая навозная яма. Реальный мир выбирает работающие технологии, а не ынтерпрайзную маркетинговую лапшу.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	29. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (9), 16-Ноя-18, 21:24
	>> Реальный мир выбирает работающие технологии Чуть-чуть не проговорился про docker, вот смешно было бы, в контексте разговора про "работающие технологии".
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	30. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Аноним (9), 16-Ноя-18, 21:27
	Эти "работающие технологии" меняются раз в пять лет. А Кобол с Явой как были так и остаются. Более того, именно они прокручивают самые ответственные системы мира этого. Но смузиедам с докером и электроном головного мозга этог не понять, не доросли.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	39. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от ананим.orig (?), 16-Ноя-18, 23:06
	> они прокручивают самые ответственные системы мира этого. Не поэтому ли ли он в опе? :D
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	42. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от Аноним (9), 17-Ноя-18, 00:11
	>>Не поэтому ли ли он в опе? :D По всем аспектам, прежде всего по количеству бабла, которое крутится в индустрии того (энтерпрайзного) софта (и по зарплатам тамошних разрабов), и по сложности и масштабности систем, которые этим софтом представлены, там всё в порядке. Ну а смузи-электронщикам только и остаётся убеждать себя в обратном.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	50. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 18-Ноя-18, 15:59
	Тут нужно просто понимать инфантильную подростковую психологию, не более. Вопрос не в языке X(икс), который популярен по тем или иным причинам в своей нише, а в детской нежной психике, которая не может этот факт адекватно воспринимать без обид и как результат - вызывает отрицание. Я вот не могу понять, что такого обидного в том, что некий язык X занимает определенную нишу. Особенно смешно выглядят глупые предложения сменить X на Y без участия здравого смысла. Создавайте решения на своем любимом ЯП которые смогут составлять конкуренцию имеющемуся ПО. Очевидно, что "хаять" язык Х на форумах значительно проще, чем "создавать решения". Нравится это местным анонимам или нет, но Жава живее всех живых. Кто не видел энтерпрайза, разуйте глаза и осознайте, что весь Андройд на жаве. Поэтому хоть ты 200 раз напиши "Не поэтому ли ли он в опе?" не менят действительности. Более чем уверен, что когда первое место займет язык Y, начнут перемывать кости ему. Завистливае дети они такие.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	16. "Выпуск сервера приложений NGINX Unit 1.6"	+3 +/–
	Сообщение от Valentin V. Bartenev (?), 16-Ноя-18, 14:13
	Поддержка Java активно разрабатывается: https://github.com/mar0x/unit/tree/java/src/java Уже даже можно начинать пробовать и оставлять отзывы. Приложения на Spring (Boot) будут работать из коробки: https://github.com/nginx/unit/issues/31#issuecomment-435018408 Скоро инструкцию туда положим.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	18. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от Аноним (18), 16-Ноя-18, 15:02
	Спасибо, это хорошая новость. А можно поинтересоваться, почему начали именно с языков семейства "пыхоплеяда"? Я тут помнится выражал мнение, что вы начали с самых тормознутых языков, -- тушить, так сказать, пожары, устроенные пыхерами. А в Java-экосистеме и без юнита все хорошо (но с юнитом станет лучше благодаря выносу работы с протоколом на уровень ниже). Но хотелось бы услышать с первых уст.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	21. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (21), 16-Ноя-18, 16:00
	Потому что там, где повсеместно используется ява, быстро внедрять nginx unit все равно не начнут в силу консерватизма.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от KonstantinB (ok), 16-Ноя-18, 16:26
	Я не знаю, но могу предположить. Интеграция того же php элементарна - пишется свой sapi-модуль и готово. А вот интегрировать с jvm их протокол на основе shared memory - это задача на порядок сложнее.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Valentin V. Bartenev (?), 16-Ноя-18, 17:43
	Это семейство языков имеет простой API для веб-приложений и легко интегрируется. Написать обертку очень просто, речь идет о считанных днях разработки. Над Java работа идет уже несколько месяцев и где-то столько же ещё впереди. Кроме того, практически вся Java - это различный энтерпрайз и вход туда требует гораздо больше начальных усилий. И то, что по-русски называется "минимально жизнеспособный продукт" - также требует больше усилий, чем, например, личный бложик на вордпрессе запускать.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	34. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от vitalif (ok), 16-Ноя-18, 22:27
	Чего там хорошо в этой яве? До сих пор на аппсерверах все сидят, и что-то кажется мне, что никуда и не слезут уже никогда...
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	51. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 18-Ноя-18, 16:22
	Субъективные понятия "хороший" и "плохой" применимы только к конкретной ситуации. Язык это всего лишь инструмент. Если он тебе не нравится, не выбирай его, выбирай то, что нравится. Кому какое дело какими кистями и красками пользуется художник? Ты когда нибудь слышал, чтобы кто-нибудь говорил что-то подобное: "Это картина не красивая, потому что художник использовал не ту кисть"?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	19. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от jOKer (ok), 16-Ноя-18, 15:12
	Ну, как по мне так он не очень нужен. В Docker Swarm Node/Kubernetes для проксирования апи, ИМХО, куда лучше работает traefik (из коробки интеграция со всеми популярными kv-хранилищами и каталогами service discovery), а для раздачи статики - проще использовать чистый nginx на выделенных серверах  - его все админы знают, да и вообще старый конь борозды не испортит. Где тут место сабжа, лично я не очень понимаю.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	20. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (9), 16-Ноя-18, 15:35
	Эта Docker Swarm глючная до невозможности, как и всё, что относится к этим всем "новомодным". А nginx-стабильнейшая и жутко производительная софтина (особенно на фоне всего этого новомодного шлака). Если сабж будет таким же как и сам nginx-будем непременно юзать его, вместо всех этих "новомодных"
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	40. "Выпуск сервера приложений NGINX Unit 1.6"	–3 +/–
	Сообщение от Аноним (10), 16-Ноя-18, 23:10
	1. nginx всего на 5 лет старше ноды, они почти ровесники. 2. nginx не всегда выигрывает по производительность у той же ноды.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

17. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
Сообщение от InuYasha (?), 16-Ноя-18, 14:25
Приложением льда ко лбу им надо заниматься. А программы пишут на C/C++.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от НяшМяш (ok), 16-Ноя-18, 20:02
	Так и новость про то, что вышла новая версия _программы_ для запуска _приложений_.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

32. "Выпуск сервера приложений NGINX Unit 1.6"	+2 +/–
Сообщение от Аноним (31), 16-Ноя-18, 22:03
Вот объясните мне плиз, люди добрые. В докладе (https://www.youtube.com/watch?v=GK6xAOVRTcg) сказано, что nginx взаимодействует с unit через разделяемую память минуя сетевой стек. А в документации сказано, что обращаться нужно к unit нужно через сокет, типа: upstream php_upstream {     server 127.0.0.1:8090; } Это как понимать? Принцип обращения через разделяемую память еще не реализован?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Выпуск сервера приложений NGINX Unit 1.6"	+2 +/–
	Сообщение от Valentin V. Bartenev (?), 16-Ноя-18, 22:33
	Речь идет о взаимодействии между процессом роутера, который асинхронно принимает и обрабатывает клиентские соединения и процессами приложений. Всё это части Unit'а и об nginx речи не идет. В документации в разделе "Integration with NGINX" рассказано о том, как можно запроксировать Unit, при желании. Но по мере обрастания возможностями, необходимости в этом будет всё меньше и меньше.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	37. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Аноним (31), 16-Ноя-18, 22:45
	Валентин, спасибо как за ответ, так и за интересный доклад. Все же остается не понятным то, чем Unit отличается от любого другого сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. Тот же uWSGI так же используется разделяемую память между мастер процессом и воркерами.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от Valentin V. Bartenev (?), 16-Ноя-18, 23:03
	> Валентин, спасибо как за ответ, так и за интересный доклад. > Все же остается не понятным то, чем Unit отличается от любого другого > сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. > Тот же uWSGI так же используется разделяемую память между мастер процессом > и воркерами. Насколько я знаю, разделяемая память там другим целям служит, а master процесс, также как и в nginx, не занимается обработкой запросов. В Unit-е есть свой такой мастер-процесс для порождения новых процессов, открытия слушающих сокетов и лог-файлов. Основное отличие в том, что Unit с самого начала проектируется чтобы смотреть наружу, в интернет, а не прятаться за реверсивным прокси. Там уже, условно говоря, есть свой, встроенный nginx - процесс роутера. Поэтому он прекрасно держит нагрузку в то время, когда uwsgi сливается: https://itnext.io/performance-comparison-between-nginx-unit-...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	41. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 16-Ноя-18, 23:38
	Сама внутренняя архитектура у Unit'а такова, что ему concurrency абсолютно до лампочки, 10 клиентов к нему придут с запросами или миллион - он будет продолжать обрабатывать запросы не снижая эффективности. Вот даже глядя на график в статье по ссылке, не трудно представить себе такую ситуацию: стоит у вас один или несколько проксирующих nginx-ов, раздают трафик на несколько uwsgi. Всё хорошо, все стабильно, каждый uwsgi-сервер обрабатывает по нескольку тысяч запросов в секунду не захлебываясь. А тут черная пятница, распродажи, маркетологи запустили очень успешную рекламную кампанию и на ваши сервера прибежали клиенты в количествах больших, чем вы предполагали. Всех этих клиентов nginx благополучно запроксировал на uwsgi и тот начал от такой конкурентности загибаться. Вместо тысяч запросов в секунду, производительность каждого сервера упала до десятков. Сайт практически лежит, вы добавляете новые сервера, а они продолжают загибаться. Менеджмент пьет валокордин и подсчитывает убытки. Теперь же другая картина и у вас не uwsgi, а Unit. Навалило клиентов, а каждый сервер с Unit'ом, как молотил 10 тыс запросов в секунду в пике так и продолжает. Видя в мониторинге, что количество запросов в секунду уперлось в потолок ваших мощностей, вы добавляете ещё несколько серверов с Unit'ом и те успешно берут на себя избыток нагрузки. Клиенты практически даже не замечают каких-то лагов.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	44. "Выпуск сервера приложений NGINX Unit 1.6"	–1 +/–
	Сообщение от _ (??), 17-Ноя-18, 04:25
	И тут в палату входят санитары \ И тут ты просыпаешься :-)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	45. "Выпуск сервера приложений NGINX Unit 1.6"	+1 +/–
	Сообщение от ыы (?), 17-Ноя-18, 09:16
	> как молотил 10 тыс запросов в секунду в пике так и продолжает То есть остальные он просто дропает? Орригинальное решение.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	47. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 17-Ноя-18, 15:50
	Ничего не дропается. Просто плавно растут задержки, запросы ждут в очереди.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	54. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 01:02
	Валентин, отличный рассказ. Ниже я вам задал вопрос про условия проведения тестов, на которые вы дали ссылку. У меня закрались сомнения, что тесты проводились в максимально производильной конфигурации. Ответьте, пожалуйста. Спасибо.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	46. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от ыы (?), 17-Ноя-18, 09:28
	>https://itnext.io/performance-comparison-between-nginx-unit-...- Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	48. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 17-Ноя-18, 15:58
	> Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках? По горизонтальной оси - количество установленных соединений, которое использовалось для одновременной отправки запросов, а по вертикальной количество запросов в секунду, которое при этом сервер обрабатывал. Там есть графики для 10 тысяч запросов и для 100 тысяч. Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	49. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Аноним (31), 17-Ноя-18, 16:59
	Валентин, спасибо за столь детальное объяснение. Теперь все понятно. Жать что пока что мало документации о внутреннем устройстве Unit и о технологических подходах который применялись при создании его.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	52. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 00:14
	Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером было: 1) через стандартный сокет, не через unix сокет? 2) через HTTP протокол, а не бинарный "uwsgi". Ведь отсюда вытекает, что тестирование uWSGI было проведено в самой непроипроизводительной конфигурации. И тогда, возможно, мы бы не увидели на графике такого "разгрома". Если эти 2 условия не были соблюдены, то врятли этим тесты можно воспринимать всерьез.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	53. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 00:48
	Вот нагуглил: 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 наиболее производительным способом. Если вы знаете это, то тогда почему этот способ не использовался?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	56. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 19-Ноя-18, 05:21
	> Вот нагуглил: > 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, а занимались более перспективными задачами. И даже данный бенчмарк не показатель, а лишь отправная точка. Ещё не всё даже реализовано так, как хотелось бы.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	57. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 11:18
	Спасибо за ответ. Я не говорил, что статья по ссылке к вам как-то относится. Из ваших слов вытекает, что при тесте использовался HTTP через TCP. >> ни uwsgi, ни unix-сокеты никак не повлияли бы на ситуацию. TCP через loopback интерфейс >> это ничтожная по ресурсам операция на фоне работы виртуальной машины cpython Вы сами себе противоречите, говоря что Unit дает преимущество, тк. там нет узкого места при взаимодействии с ВМ. И тут же пишите, что ВМ узкое место и юникс сокеты с бинарным протоколом ничего не решат, тк даже loopback интерфейс прекрасен и не является узким местом. Я вам указываю, лишь на то, что unix socket + бинарный протокол даст больше производительности и слабо верю в те сферические 2%. Может быть все же 20%? 1) В Unix сокетах нет буферизации и логики роутинга. Я находил в инете цифры 10-20% большей произв-ти по сравнению с TCP. 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP. Так что давайте остановимся на цифре +20% и "разгром", следовательно, отменяется. Вы же понимаете, что странно устраивать тест на производительность и допустить такую оплошность. Именно поэтому нужно задействовать unix socket + бинарный протокол и провести тесты заново. Тогда не будет никаких сомнений в "разгроме".
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 19-Ноя-18, 15:27
	[..] > 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, так что каждый может скачать и убедиться. Зачем мне что-то доказывать, если есть продукт, который говорит сам за себя. Успехов!
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	62. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от angra (ok), 20-Ноя-18, 02:15
	> 2) Адекватному программисту понятно, что бинарный протокол будет иделывать(в разы) строковый протокол такой как HTTP. Адекватному программисту ясно, что это сильно зависит от данных. Если данные состоят в основном из чисел, то разница будет заметной. Если же данные большей частью состоят из строк да еще и без экранирования, то разница почти нулевая.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	63. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 20-Ноя-18, 11:00
	Вот копипаста от разрабов 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 вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков и их значений, то есть это парсинг вслепую. В то же самое время можно задавать длины полей, и парсинг будет происходить четко пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или нет, не имеет значения.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	65. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 20-Ноя-18, 13:24
	> Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков > и их значений, то есть это парсинг вслепую. В то же > самое время можно задавать длины полей, и парсинг будет происходить четко > пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это > типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или > нет, не имеет значения. 1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам. 2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать. Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует. В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую. Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	58. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 11:49
	Также в тестах, насколько я понял, нет uSWGI c Go. А то я скорее вижу там как в лоб сравнивается производительность Go с Python. Это добавляет еще большей сферичности вашим тестам.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	59. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 19-Ноя-18, 12:03
	Итого нужны тесты: 1) Unit + Go vs Unix Socket + binary uswgi + Go 2) Unit + Python vs Unix Socket + binary uswgi + Python Тогда это будет не маркетинговый тест.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 19-Ноя-18, 15:29
	> Итого нужны тесты: > 1) Unit + Go vs Unix Socket + binary uswgi + Go > 2) Unit + Python vs Unix Socket + binary uswgi + Python > Тогда это будет не маркетинговый тест. Уточните, а кто должен общаться с uWSGI по его "binary" протоколу? Клиенты этого делать не умеют.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	64. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Ку (?), 20-Ноя-18, 11:02
	Очевидно, что Nginx.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	55. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
	Сообщение от Valentin V. Bartenev (?), 19-Ноя-18, 04:36
	> Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером > было: В данной статье nginx вообще нет.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

35. "Выпуск сервера приложений NGINX Unit 1.6"	+/–
Сообщение от vitalif (ok), 16-Ноя-18, 22:28
Все-таки мне кажется, что не будет это востребовано. Толстосерверы не в моде
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема