Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
S.A.N
nginx-forum на forum.nginx.org
Вс Июн 5 01:44:42 UTC 2016
> > 1 запрос выполняется за 100ms
> >
> > Если послать 30 последовательных запросов в 1 соединение мы получим
> 30
> > ответов за 3000ms
> > Если послать 30 запросов в 30 разных соединениях мы получим 30
> ответов за
> > 100ms
> > Если послать 30 асинхронных запросов в 1 соединение мы получим 30
> ответов за
> > 100ms
> >
> > В первом варианте, 1 сокет находится в режиме busy 3000ms
> > В втором варианте, 30 сокетов находится в режиме busy 100ms
> > В третьем варианте, 1 сокет находится в режиме busy ~0ms
>
> Интересная математика, т.е. в третьем варианте у вас 30 запросов
> приложение отработало за 0ms, при том, что по вашему же условию 1
> запрос выполняется 100ms?
Нет, в третьем варианте, 30 запросов отработают за 100ms, это же указанно
чуть выше.
Но сокет в третьем варианте, будет занят 0ms, это означает что на протяжении
этих 100ms, вы можете продолжать отправлять новые запросы в этот же сокет,
не дожидаясь ответов на предыдущие 30 запросов, т.е. сокет всегда готов
принимать новые запросы.
Это очень упрощает алгоритм отправки новых запросов, вы постоянно говорите
про сложности которые создает мультиплексирования, но я вижу, что он дает
только плюсы и упрощения алгоритмов.
> Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30
> виртуальных
> сокетов внутри этого самого мультиплексированного соединения.
30 виртуальных сокетов - это 30 объектов Request/Respons в которых есть свой
id и указатель на свой сокет.
Сейчас без мультиплексирования эти 30 объектов тоже создаются, но без id.
Так что ничего особо сложного в коде бекенд приложений делать не придется.
Возможно для низкоуровневых бекенд приложений это большие сложности, но для
приложений на Go, Python, Node.js, PHP демоны, это не добавит особых
сложностей.
> Протоколу FastCGI, который умеет мультиплекирование, уже много-много
> лет.
> Как вы думаете, почему за все это время никто это самое
> мультиплексирование
> в нем не использует? Ответ прост - потому что это сложно и
> неэффективно.
Нет, ответ ещё проще, 80% сайтов работает на РНР, который "умирает" после
выполнения запроса и в процессе работы весь его I/O с блокировкой.
Использовать мультиплексирования в PHP-FPM это так же бессмысленно как
использовать антикрыло в грузовиках, по этому его там никто не использует,
но это совсем не значит что мультиплексирование не эффективная технология,
люди которые создавали FastCGI просто опережали свое время.
Я понимаю что мой юзкейс (запросы между бекендами через Nginx) редкость для
других пользователей Nginx, но только там я увидел как быстро улетает 1024
fd на простых задачах без особых нагрузок.
Жить конечно можно, мы увеличили лимиты fd, создали пулы keep-alive, но есть
ощущения что нет смысла тратить столько fd.
Реализовать мультиплексирование на бекенде не сложно, но жаль нельзя
проверить на тестах, чтобы убедится так ли это или нет.
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267387#msg-267387
Подробная информация о списке рассылки nginx-ru