Persistent HTTP connections как раз и способствуют
более быстрой обработке backend`ом запросов, потому
что не нужно будет для обработки следующего запроса
каждый раз заново устанавливать tcp-соединение.
убирается лишний overhead, экономятся ресурсы.
Теоретически, да. Но на практике frontend и backend соедены достаточно быстрой сетью и этот оверхед
принебрежимо мал.
Небольшой тест:
$ ab -n 5000
...
Requests per second: 452.49 [#/sec] (mean)
Time per request: 2.21 [ms] (mean)
$ ab -k -n 5000
...
Requests per second: 706.71 [#/sec] (mean)
Time per request: 1.41 [ms] (mean)
И того, мы на Keep-Alive мы сэкономили 0.80 ms на один запрос.
(машины соеденены стомегабитной сетью, на гигабите разница будет меньше)
Типичное время ответа бэкенда раздающего динамику - 100 ms
Т. е. Keep-Alive позволит его сократить примерно на 1%.
Pipelining - это способ еще больше ускорить обработку
запросов, потому что клиент может отправить несколько
запросов "пачкой" не дожидаясь завершения обработки
предыдущего запроса перед отправкой следующего,
тогда backend вообще не будет простаивать
в ожидании нового запроса от frontend`а
после обработки предыдущего.
Как это выглядит с точки зрения фронтенда:
сейчас как только получен запрос от клиента, посылается запрос на бэкенд
если делать pipelining то фронтенд должен будет подождать еще один запрос (немного увелилчивая response time
для первого), потом послать оба зпроса разом.
С точки зрения бэкенда:
- если он обрабатывает запросы быстрее чем они поступают, то часть времени он все равно будет ждать нового
запроса и простаивать; это нормальный режим работы.
- если он перегружен, то он и без pipelining-а ничего не ждет и не простаивает. Как только отдан ответ
текущего запроса, делает accept на коннекцию, которая ожидает в listen queue и начинает обрабатываться
следующий запрос.
Сами по себе Keep-Alive и Pipelining это конечно полезные возможности протокола HTTP, но реально нужны они
только на участке между конечным клиентом (который обычно имеет сравнительно медленный канал) и сервером.
