Welcome! Log In Create A New Profile

Advanced

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

Валентин Бартенев
June 04, 2016 07:02PM
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 mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Subject Author Posted

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

Иван June 01, 2016 01:14PM

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

Maxim Dounin June 01, 2016 02:00PM

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

S.A.N June 01, 2016 03:25PM

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

Валентин Бартенев June 03, 2016 04:46PM

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

Vadim A. Misbakh-Soloviov June 03, 2016 05:50PM

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

S.A.N June 03, 2016 07:26PM

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

Konstantin Tokarev June 04, 2016 10:42AM

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

S.A.N June 04, 2016 04:15PM

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

Валентин Бартенев June 04, 2016 07:02PM

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

S.A.N June 04, 2016 09:44PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 262
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready