Persistent HTTP connections && Pipelining

[Konstantin Svist]

Kostya Alexandrov wrote:
> Совершенно верно ты понял, это надстройка над кип алайв.
>
> Pipelining имеет смысл только в том случае если
> 1. ты шлеш (лигика приложения требует/позволяет, броузеры так делают и 
> т.п.) новые запросы не дождавшись ответа
> 2. тебе не критичен порядок ответов.
>
> Отсюда он НЕ сможет сильно разгрузить бекенд сам по себе, если 
> поддержка его формальна.
> Например в случае с апачем как бекендом толку особого небудет.

А я как раз пытаюсь разгрузить количество соединений (из-за проблемы с 
моим брандмауером, в основном) - не разгрузить бекенд. Для разгрузки 
бекенда у меня сейчас squid сидит.
Сервер, кстати, не Apache.


> В случае проксирующего софта, иметь pipelined конекшен с бекендом и НЕ 
> pipelined с клиентом нельзя.
> т.к. без спецальных подкидываний, и поддержки чего то типа реквест 
> айди на бекенде определить какой ответ
> кому отдать невозможно. Т.е. можно только если каждое кипаливное 
> соединение клиента с ngnix проксируется
> в одно кипаливное соединение с бекендом.Однако имеет полный смысл если 
> клиент устанавливает киип алайв
> соединение, и шлет следующий запрос послать его бекенду в том же сокете.

Если думать о прокси как клиент/сервер (со стороны клиента, сервер; со 
стороны сервера, клиент), то кажется что должно быть возможно. Другое 
дело что будет тяжело держать id каждого запроса..
А если клиент устанавливает keep-alive, использует ли nginx keep-alive к 
обращению к серверу? Или всё-таки делает отдельные запросы? Если уже 
поддерживает, то мне клиент надо лупасить :)


> Konstantin Svist wrote:
>> Anton Yuzhaninov wrote:
>>>>
>>>> Pipelining - это способ еще больше ускорить обработку
>>>> запросов, потому что клиент может отправить несколько
>>>> запросов "пачкой" не дожидаясь завершения обработки
>>>> предыдущего запроса перед отправкой следующего,
>>>> тогда backend вообще не будет простаивать
>>>> в ожидании нового запроса от frontend`а
>>>> после обработки предыдущего.
>>>>
>>>
>>> Как это выглядит с точки зрения фронтенда:
>>>
>>> сейчас как только получен запрос от клиента, посылается запрос на 
>>> бэкенд
>>>
>>> если делать pipelining то фронтенд должен будет подождать еще один 
>>> запрос (немного увелилчивая response time для первого), потом 
>>> послать оба зпроса разом.
>>
>> Ничего подобного. Насколько я понимаю:
>> * pipelining только имеет смысл когда используется keep-alive.
>> * Без keep-alive: каждый запрос приходит в отдельном соединении 
>> (параллельно).
>> * С keep-alive, без pipelining: новый запрос приходит только когда 
>> предыдущий запрос вернулся (поочерёдно).
>> * С keep-alive, с pipelining: новый запрос может быть послан по 
>> уже-существующему соединению. Побочный эффект: несколько запросов 
>> можно послать в одном пакете - но не обязательно.
>>
>> Или может я что-то не так понял..?
>>
>>
>>
>>
>
>