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 — это одна из реализаций wsgi application server-а и одноименный бинарный протокол, придуманный авторами uswgi.
Во-вторых, большинство wsgi app-серверов (включая uwsgi) умеют отвечать по http.
| |
3.31, Аноним (31), 21:41, 16/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
>С nginx unit все упрощается - nginx + uwsgi заменяется на nginx unit.
Вообще-то uwsgi может выступать в качестве веб-сервера. По сему в связке nginx + uwsgi, nginx лишний.
| |
|
|
5.43, Аноним (43), 02:19, 17/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Подселять по энжиниксу к каждому экземпляру uwsgi действительно излине. Большую часть того, что бэкендеры обычно хотят от творения Сысоева, успешно можно сделать средствами uwsgi (рерайты, редиректы, работа с заголовками итд). Остальное уже спокойно делается на тех энжиниксах, которые балансируют нагрузку между бэкендами (тем более, что у любителя энжиникса в сайдкарах по определению кубернетес и, скорее всего, используются ингрессы с энжиниксом)
| |
|
|
3.66, user455 (?), 16:57, 26/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
а пайтоновские фреймворки сами как веб сервер не умеют запускаться?
зачем там нужен нгинкс в каждом контейнере?
нгинкс логично ставить на балансер, а там аппликейшн саппорт как-то и не нужен. разве нет?
| |
|
2.3, Аноним (3), 09:07, 16/11/2018 [^] [^^] [^^^] [ответить]
| –9 +/– |
Так посмотри на список поддерживаемых языков/платформ:
> Python, PHP, Perl, Ruby, Go и JavaScript/Node.js
Пихон, пых, устаревший перл, нескучный руби, го-секта и вспомнити лефтпад.
Я бы дождался поддержки Java для начала. С ее появлением уже может пойти речь о чем-то взрослом, серьезном.
| |
|
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 сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься.
| |
|
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 [^] [^^] [^^^] [ответить]
| +/– |
> На яве пишут бизнес-логику, а сам бэкенд на других языках. Тот же paypal сменил бэкенд на Node.js. Не надо здесь диванной аналитики, т.к. на опеннете есть люди, которые в этой сфере работают. Не позорься
#s/бэкенд/фронтэд/
| |
|
5.24, Аноним (24), 18:04, 16/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Это ты хорошо яву с коболом сравнил. Звиняй, для реального мира навозная яма в которой копошатся банкиры и финансисты со своими коболами, жавами, 1C и оракалами совершенно побоку, тем более как ориентир для выбора технологий. Это не взрослость, это просто узкоспецифичная вонючая навозная яма. Реальный мир выбирает работающие технологии, а не ынтерпрайзную маркетинговую лапшу.
| |
|
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 [^] [^^] [^^^] [ответить] | +/– | Тут нужно просто понимать инфантильную подростковую психологию, не более Вопрос... текст свёрнут, показать | |
|
|
|
|
|
|
4.18, Аноним (18), 15:02, 16/11/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Спасибо, это хорошая новость.
А можно поинтересоваться, почему начали именно с языков семейства "пыхоплеяда"? Я тут помнится выражал мнение, что вы начали с самых тормознутых языков, -- тушить, так сказать, пожары, устроенные пыхерами. А в Java-экосистеме и без юнита все хорошо (но с юнитом станет лучше благодаря выносу работы с протоколом на уровень ниже). Но хотелось бы услышать с первых уст.
| |
|
5.21, Аноним (21), 16:00, 16/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что там, где повсеместно используется ява, быстро внедрять nginx unit все равно не начнут в силу консерватизма.
| |
5.22, KonstantinB (ok), 16:26, 16/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Я не знаю, но могу предположить.
Интеграция того же php элементарна - пишется свой sapi-модуль и готово.
А вот интегрировать с jvm их протокол на основе shared memory - это задача на порядок сложнее.
| |
5.23, Valentin V. Bartenev (?), 17:43, 16/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это семейство языков имеет простой API для веб-приложений и легко интегрируется. Написать обертку очень просто, речь идет о считанных днях разработки. Над Java работа идет уже несколько месяцев и где-то столько же ещё впереди.
Кроме того, практически вся Java - это различный энтерпрайз и вход туда требует гораздо больше начальных усилий. И то, что по-русски называется "минимально жизнеспособный продукт" - также требует больше усилий, чем, например, личный бложик на вордпрессе запускать.
| |
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 для проксирования апи, ИМХО, куда лучше работает traefik (из коробки интеграция со всеми популярными kv-хранилищами и каталогами service discovery), а для раздачи статики - проще использовать чистый nginx на выделенных серверах - его все админы знают, да и вообще старый конь борозды не испортит. Где тут место сабжа, лично я не очень понимаю.
| |
|
3.20, Аноним (9), 15:35, 16/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Эта Docker Swarm глючная до невозможности, как и всё, что относится к этим всем "новомодным". А nginx-стабильнейшая и жутко производительная софтина (особенно на фоне всего этого новомодного шлака). Если сабж будет таким же как и сам nginx-будем непременно юзать его, вместо всех этих "новомодных"
| |
|
4.40, Аноним (10), 23:10, 16/11/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
1. nginx всего на 5 лет старше ноды, они почти ровесники.
2. nginx не всегда выигрывает по производительность у той же ноды.
| |
|
|
|
|
2.27, НяшМяш (ok), 20:02, 16/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Так и новость про то, что вышла новая версия _программы_ для запуска _приложений_.
| |
|
1.32, Аноним (31), 22:03, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Вот объясните мне плиз, люди добрые. В докладе (https://www.youtube.com/watch?v=GK6xAOVRTcg) сказано, что nginx взаимодействует с unit через разделяемую память минуя сетевой стек. А в документации сказано, что обращаться нужно к unit нужно через сокет, типа:
upstream php_upstream {
server 127.0.0.1:8090;
}
Это как понимать? Принцип обращения через разделяемую память еще не реализован?
| |
|
2.36, Valentin V. Bartenev (?), 22:33, 16/11/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Речь идет о взаимодействии между процессом роутера, который асинхронно принимает и обрабатывает клиентские соединения и процессами приложений. Всё это части Unit'а и об nginx речи не идет.
В документации в разделе "Integration with NGINX" рассказано о том, как можно запроксировать Unit, при желании. Но по мере обрастания возможностями, необходимости в этом будет всё меньше и меньше.
| |
|
3.37, Аноним (31), 22:45, 16/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Валентин, спасибо как за ответ, так и за интересный доклад.
Все же остается не понятным то, чем Unit отличается от любого другого сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. Тот же uWSGI так же используется разделяемую память между мастер процессом и воркерами.
| |
|
4.38, Valentin V. Bartenev (?), 23:03, 16/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Валентин, спасибо как за ответ, так и за интересный доклад.
> Все же остается не понятным то, чем Unit отличается от любого другого
> сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx.
> Тот же uWSGI так же используется разделяемую память между мастер процессом
> и воркерами.
Насколько я знаю, разделяемая память там другим целям служит, а master процесс, также как и в nginx, не занимается обработкой запросов. В Unit-е есть свой такой мастер-процесс для порождения новых процессов, открытия слушающих сокетов и лог-файлов.
Основное отличие в том, что Unit с самого начала проектируется чтобы смотреть наружу, в интернет, а не прятаться за реверсивным прокси. Там уже, условно говоря, есть свой, встроенный nginx - процесс роутера. Поэтому он прекрасно держит нагрузку в то время, когда uwsgi сливается: https://itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-
| |
|
5.41, Valentin V. Bartenev (?), 23:38, 16/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Сама внутренняя архитектура у Unit'а такова, что ему concurrency абсолютно до лампочки, 10 клиентов к нему придут с запросами или миллион - он будет продолжать обрабатывать запросы не снижая эффективности.
Вот даже глядя на график в статье по ссылке, не трудно представить себе такую ситуацию: стоит у вас один или несколько проксирующих nginx-ов, раздают трафик на несколько uwsgi. Всё хорошо, все стабильно, каждый uwsgi-сервер обрабатывает по нескольку тысяч запросов в секунду не захлебываясь. А тут черная пятница, распродажи, маркетологи запустили очень успешную рекламную кампанию и на ваши сервера прибежали клиенты в количествах больших, чем вы предполагали. Всех этих клиентов nginx благополучно запроксировал на uwsgi и тот начал от такой конкурентности загибаться. Вместо тысяч запросов в секунду, производительность каждого сервера упала до десятков. Сайт практически лежит, вы добавляете новые сервера, а они продолжают загибаться. Менеджмент пьет валокордин и подсчитывает убытки.
Теперь же другая картина и у вас не uwsgi, а Unit. Навалило клиентов, а каждый сервер с Unit'ом, как молотил 10 тыс запросов в секунду в пике так и продолжает. Видя в мониторинге, что количество запросов в секунду уперлось в потолок ваших мощностей, вы добавляете ещё несколько серверов с Unit'ом и те успешно берут на себя избыток нагрузки. Клиенты практически даже не замечают каких-то лагов.
| |
|
6.44, _ (??), 04:25, 17/11/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
И тут в палату входят санитары \ И тут ты просыпаешься
:-)
| |
6.45, ыы (?), 09:16, 17/11/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> как молотил 10 тыс запросов в секунду в пике так и продолжает
То есть остальные он просто дропает?
Орригинальное решение.
| |
6.54, Ку (?), 01:02, 19/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Валентин, отличный рассказ.
Ниже я вам задал вопрос про условия проведения тестов, на которые вы дали ссылку.
У меня закрались сомнения, что тесты проводились в максимально производильной конфигурации.
Ответьте, пожалуйста.
Спасибо.
| |
|
|
6.48, Valentin V. Bartenev (?), 15:58, 17/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?
По горизонтальной оси - количество установленных соединений, которое использовалось для одновременной отправки запросов, а по вертикальной количество запросов в секунду, которое при этом сервер обрабатывал.
Там есть графики для 10 тысяч запросов и для 100 тысяч.
Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.
| |
|
7.49, Аноним (31), 16:59, 17/11/2018 [^] [^^] [^^^] [ответить]
| +/– |
Валентин, спасибо за столь детальное объяснение. Теперь все понятно. Жать что пока что мало документации о внутреннем устройстве Unit и о технологических подходах который применялись при создании его.
| |
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-djan... текст свёрнут, показать | |
|
|
10.57, Ку (?), 11:18, 19/11/2018 [^] [^^] [^^^] [ответить] | +/– | Спасибо за ответ Я не говорил, что статья по ссылке к вам как-то относится Из ... текст свёрнут, показать | |
|
11.62, angra (ok), 02:15, 20/11/2018 [^] [^^] [^^^] [ответить] | +/– | Адекватному программисту ясно, что это сильно зависит от данных Если данные сос... текст свёрнут, показать | |
|
12.63, Ку (?), 11:00, 20/11/2018 [^] [^^] [^^^] [ответить] | +/– | Вот копипаста от разрабов uWSGi Why not simply use HTTP as the protocol A good... текст свёрнут, показать | |
|
|
10.58, Ку (?), 11:49, 19/11/2018 [^] [^^] [^^^] [ответить] | +/– | Также в тестах, насколько я понял, нет uSWGI c Go А то я скорее вижу там как в ... текст свёрнут, показать | |
10.59, Ку (?), 12:03, 19/11/2018 [^] [^^] [^^^] [ответить] | +/– | Итого нужны тесты 1 Unit Go vs Unix Socket binary uswgi Go 2 Unit Pyt... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
1.35, vitalif (ok), 22:28, 16/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все-таки мне кажется, что не будет это востребовано. Толстосерверы не в моде
| |
|