- Выпуск сервера приложений NGINX Unit 1.6, max, 08:44 , 16-Ноя-18 (1)
- Выпуск сервера приложений NGINX Unit 1.6, Eduard, 09:03 , 16-Ноя-18 (2) –4 [V]
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 09:07 , 16-Ноя-18 (3) –9 [V]
- Выпуск сервера приложений NGINX Unit 1.6, ыы, 09:12 , 16-Ноя-18 (4) +13 [^]
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 14:13 , 16-Ноя-18 (16) +3
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 15:02 , 16-Ноя-18 (18) –1
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 16:00 , 16-Ноя-18 (21) +1
- Выпуск сервера приложений NGINX Unit 1.6, KonstantinB, 16:26 , 16-Ноя-18 (22)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 17:43 , 16-Ноя-18 (23) +1
Это семейство языков имеет простой API для веб-приложений и легко интегрируется. Написать обертку очень просто, речь идет о считанных днях разработки. Над Java работа идет уже несколько месяцев и где-то столько же ещё впереди.Кроме того, практически вся Java - это различный энтерпрайз и вход туда требует гораздо больше начальных усилий. И то, что по-русски называется "минимально жизнеспособный продукт" - также требует больше усилий, чем, например, личный бложик на вордпрессе запускать.
- Выпуск сервера приложений NGINX Unit 1.6, vitalif, 22:27 , 16-Ноя-18 (34) –1
- Выпуск сервера приложений NGINX Unit 1.6, jOKer, 15:12 , 16-Ноя-18 (19)
- Выпуск сервера приложений NGINX Unit 1.6, InuYasha, 14:25 , 16-Ноя-18 (17) +1
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 22:03 , 16-Ноя-18 (32) +2
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 22:33 , 16-Ноя-18 (36) +2
Речь идет о взаимодействии между процессом роутера, который асинхронно принимает и обрабатывает клиентские соединения и процессами приложений. Всё это части Unit'а и об nginx речи не идет.В документации в разделе "Integration with NGINX" рассказано о том, как можно запроксировать Unit, при желании. Но по мере обрастания возможностями, необходимости в этом будет всё меньше и меньше.
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 22:45 , 16-Ноя-18 (37) +1
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 23:03 , 16-Ноя-18 (38) +1
> Валентин, спасибо как за ответ, так и за интересный доклад. > Все же остается не понятным то, чем Unit отличается от любого другого > сервера приложений в разрезе цепочки взаимодействия от запускаемого приложения до nginx. > Тот же uWSGI так же используется разделяемую память между мастер процессом > и воркерами.Насколько я знаю, разделяемая память там другим целям служит, а master процесс, также как и в nginx, не занимается обработкой запросов. В Unit-е есть свой такой мастер-процесс для порождения новых процессов, открытия слушающих сокетов и лог-файлов. Основное отличие в том, что Unit с самого начала проектируется чтобы смотреть наружу, в интернет, а не прятаться за реверсивным прокси. Там уже, условно говоря, есть свой, встроенный nginx - процесс роутера. Поэтому он прекрасно держит нагрузку в то время, когда uwsgi сливается: https://itnext.io/performance-comparison-between-nginx-unit-...
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 23:38 , 16-Ноя-18 (41)
Сама внутренняя архитектура у Unit'а такова, что ему concurrency абсолютно до лампочки, 10 клиентов к нему придут с запросами или миллион - он будет продолжать обрабатывать запросы не снижая эффективности.Вот даже глядя на график в статье по ссылке, не трудно представить себе такую ситуацию: стоит у вас один или несколько проксирующих nginx-ов, раздают трафик на несколько uwsgi. Всё хорошо, все стабильно, каждый uwsgi-сервер обрабатывает по нескольку тысяч запросов в секунду не захлебываясь. А тут черная пятница, распродажи, маркетологи запустили очень успешную рекламную кампанию и на ваши сервера прибежали клиенты в количествах больших, чем вы предполагали. Всех этих клиентов nginx благополучно запроксировал на uwsgi и тот начал от такой конкурентности загибаться. Вместо тысяч запросов в секунду, производительность каждого сервера упала до десятков. Сайт практически лежит, вы добавляете новые сервера, а они продолжают загибаться. Менеджмент пьет валокордин и подсчитывает убытки. Теперь же другая картина и у вас не uwsgi, а Unit. Навалило клиентов, а каждый сервер с Unit'ом, как молотил 10 тыс запросов в секунду в пике так и продолжает. Видя в мониторинге, что количество запросов в секунду уперлось в потолок ваших мощностей, вы добавляете ещё несколько серверов с Unit'ом и те успешно берут на себя избыток нагрузки. Клиенты практически даже не замечают каких-то лагов.
- Выпуск сервера приложений NGINX Unit 1.6, ыы, 09:28 , 17-Ноя-18 (46)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 15:58 , 17-Ноя-18 (48)
> Я дико извиняюсь, но не могли бы вы объяснить что изображено на графиках?По горизонтальной оси - количество установленных соединений, которое использовалось для одновременной отправки запросов, а по вертикальной количество запросов в секунду, которое при этом сервер обрабатывал. Там есть графики для 10 тысяч запросов и для 100 тысяч. Соответственно в самой левой части графика все 10 или 100 тысяч запросов отправлялись последовательно по одному соединению и сервер обрабатывал их с указанной скоростью. В самой правой части графика запросы отправлялись одновременно по 500 соединениям.
- Выпуск сервера приложений NGINX Unit 1.6, Аноним, 16:59 , 17-Ноя-18 (49)
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 00:14 , 19-Ноя-18 (52)
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 00:48 , 19-Ноя-18 (53)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 05:21 , 19-Ноя-18 (56)
> Вот нагуглил: > 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, а занимались более перспективными задачами. И даже данный бенчмарк не показатель, а лишь отправная точка. Ещё не всё даже реализовано так, как хотелось бы.
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 11:18 , 19-Ноя-18 (57)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 15:27 , 19-Ноя-18 (60)
[..] > 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, так что каждый может скачать и убедиться. Зачем мне что-то доказывать, если есть продукт, который говорит сам за себя. Успехов!
- Выпуск сервера приложений NGINX Unit 1.6, angra, 02:15 , 20-Ноя-18 (62)
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 11:00 , 20-Ноя-18 (63)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 13:24 , 20-Ноя-18 (65)
> Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков > и их значений, то есть это парсинг вслепую. В то же > самое время можно задавать длины полей, и парсинг будет происходить четко > пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это > типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или > нет, не имеет значения.1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам. 2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать. Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует. В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую. Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 11:49 , 19-Ноя-18 (58)
- Выпуск сервера приложений NGINX Unit 1.6, Ку, 12:03 , 19-Ноя-18 (59)
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 15:29 , 19-Ноя-18 (61)
> Итого нужны тесты: > 1) Unit + Go vs Unix Socket + binary uswgi + Go > 2) Unit + Python vs Unix Socket + binary uswgi + Python > Тогда это будет не маркетинговый тест.Уточните, а кто должен общаться с uWSGI по его "binary" протоколу? Клиенты этого делать не умеют.
- Выпуск сервера приложений NGINX Unit 1.6, Valentin V. Bartenev, 04:36 , 19-Ноя-18 (55)
> Правильно ли я понимаю, что при тесте взаимодействие Nginx с uWSGI сервером > было: В данной статье nginx вообще нет.
- Выпуск сервера приложений NGINX Unit 1.6, vitalif, 22:28 , 16-Ноя-18 (35)
|