> Можете расшифровать выражение "сокет не простаивал в пустую"? Чем > грозит > сокет, который простаивает впустую? Что по вашему такой сокет > потребляет: > ресурсы процессора, электричество, солярку, деньги?
Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память приложения, мы используем libev. Один сокет требует, создания одного WatcherObject и одного HandlerMethod, это не много, но они 70% времени ничего не делают, потому что время выполнения запроса в десятки раз превышает время передачи данных по локальному сокету. Это не важно когда запросов не много, но когда частота запросов высокая, открывать новые соединения, на каждый запрос это расточительно и глупо. Зачем открывать новое соединения, если в бекенд приложении уже и так есть 100 busy сокетов, которые ничего не делают, потому что ждут ответа на предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне HTTP/1.х, хотя сокет non-blocking mode. Мультиплексирование убирает понятие socket busy, бекенд приложению будет достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю его снова: 1 запрос выполняется за 100ms Если послать 30 последовательных запросов в 1 соединение мы получим 30 ответов за 3000ms Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за 100ms Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за 100ms В первом варианте, 1 сокет находится в режиме busy 3000ms В втором варианте, 30 сокетов находится в режиме busy 100ms В третьем варианте, 1 сокет находится в режиме busy ~0ms Вопрос какой из трех вариантов более эффективно использует ресурсы? Мультиплексирование - нужно всем бекенд приложениям, у которых есть временное окно между запросом и ответом, чем больше это временное окно, тем больше позитив эффекта от мультиплексирование. Сокеты - это как нефть, её много, но ресурс ограничен Мультиплексирование - это как сланцевая нефть, она дает возможность использовать ту нефть, которая ранее считались не пригодная к использованию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267369#msg-267369 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru