Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?

Валентин Бартенев vbart на nginx.com
Сб Июн 4 22:54:38 UTC 2016


On Friday 03 June 2016 19:26:38 S.A.N wrote:
> > Можете расшифровать выражение "сокет не простаивал в пустую"?  Чем
> > грозит
> > сокет, который простаивает впустую?  Что по вашему такой сокет
> > потребляет:
> > ресурсы процессора, электричество, солярку, деньги?
> 
> Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память
> приложения, мы используем libev.
> Один сокет требует, создания одного WatcherObject и одного HandlerMethod,
> это не много, но они 70% времени ничего не делают, потому что время
> выполнения запроса в десятки раз превышает время передачи данных по
> локальному сокету.

Т.е. вся проблем состоит в том, что вы это так неэффективно запрограммировали
ваше приложение, а мультиплексирование служит лишь поводом изменить его логику 
работы на более эффективную?  Почему бы просто не изменить её?


> 
> Это не важно когда запросов не много, но когда частота запросов высокая,
> открывать новые соединения, на каждый запрос это расточительно и глупо.
> 

Расточительно конкретно в вашем приложении?


> Зачем открывать новое соединения, если в бекенд приложении уже и так есть
> 100 busy сокетов, которые ничего не делают, потому что ждут ответа на
> предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне
> HTTP/1.х, хотя сокет non-blocking mode.

Ничего не делать и ждать ответа - это несколько разные вещи, не нужно их
приравнивать.


> 
> Мультиплексирование убирает понятие socket busy, бекенд приложению будет
> достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше
> WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю
> его снова:

Почему бы не решить проблему с "WatcherObject и HandlerMethod", а не пытаться
выдавать проблему конкретного неудачного подхода за проблему протокола?

В использовании нескольких сокетов, по одному на запрос, нет ровным счетом 
ничего плохого.  Вы пытаетесь доказать, что сокеты плохи, описывая, как 
работает ваше приложение.  Но может быть дело не в сокетах, а в том,
что ваше приложение использует ресурсы неэффективно?

Любое мультиплексирование нескольких соединений внутри другого соединения 
является усложнением, а усложнение приводит к трате большего числа ресурсов.

От того, что вы замените TCP сокеты на виртуальные сокеты внутри одного
мультиплексированного соединения, вы просто замените одни идентификаторы
на другие.  И у вас точно также будут "простаивать" те самые виртуальные 
идентификаторы и все ресурсы, что с ними связаны, и расходовать память.

Каким образом замена одних id на другие id что-то меняет?


> 
> 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?


> Вопрос какой из трех вариантов более эффективно использует ресурсы?

Вариант номер 1 и 2.  Поскольку третий вариант требует более сложного 
протокола и логики работы, что требует большего числа ресурсов.

Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30 виртуальных 
сокетов внутри этого самого мультиплексированного соединения.

Протоколу FastCGI, который умеет мультиплекирование, уже много-много лет.
Как вы думаете, почему за все это время никто это самое мультиплексирование
в нем не использует?  Ответ прост - потому что это сложно и неэффективно.

С HTTP/2 в upstream та же история, это сложно и неэффективно.


> 
> Мультиплексирование - нужно всем бекенд приложениям, у которых есть
> временное окно между запросом и ответом, чем больше это временное окно, тем
> больше позитив эффекта от мультиплексирование.
> 
> Сокеты - это как нефть, её много, но ресурс ограничен
> Мультиплексирование - это как сланцевая нефть, она дает возможность
> использовать ту нефть, которая ранее считались не пригодная к использованию.
> 

Сокеты - это котятки, каждый раз когда рождается новый, ну вы понимаете...

--
Валентин Бартенев


Подробная информация о списке рассылки nginx-ru