Persistent HTTP connections && Pipelining

[Kostya Alexandrov]

Уважаемый, MZ, позвольте не согласится с Вами.
Я вижу большое количество проблем при подобной реализации персистент 
конекта к бекенду.
Как раз то что вы предлагаете может просадить производительность 
достаточно сильно на перекладывании по буферам,
отслеживании ответа и т.п. От описанных Вами проблем спасет только 
keep-alive. pipelining имеет смысл только если
он поддерживается бекендом.

Мое мнение что реализация персистент конекта должна быть следующей:
- keep-alive с бекендом, если тот его поддерживает по дефолту
- спецальной директивой проксировать piplining от клиента в то же 
соединение с бекендом что и первый запрос.
   но это ОБЯЗАТЕЛЬНО на конфиг. Т.е. директива типа proxy_pass_pipe. и 
тогда один клиентский конекшен транслируется
   в один  конекшен с бекендом.

Во всех остальных случаях имхо будет криво.

MZ wrote:
> В ср, 14/11/2007 в 13:48 +0300, Igor Sysoev пишет:
>   
>> On Wed, Nov 14, 2007 at 12:09:31PM +0200, MZ wrote:
>>
>>     
>>> В ср, 14/11/2007 в 10:12 +0300, Igor Sysoev пишет:
>>>       
>>>> Persistent соединения с бэкендом планируются, но реализовать их на данный
>>>> момент сложно, так как необходимо обрабатывать chunked ответы бэкенда.
>>>> Большого прироста производительности ожидать от этого не стоит,
>>>> за исключением случаев, когда бэкенд на виндах или джаве.
>>>>         
>>> Не сказал бы что не стоит. Оверхед не только на установку и accept
>>> соединения (а чем больше очередь входящих соединений тем надо больше
>>> ресурсов на её обработку). Но и на поиск или инициализацию свободного
>>> воркера куда можно было бы пробросить соединение, освобождение воркера
>>> после отдачи контента, ... - это все тоже работа, причем большая чем
>>> просто установка соединения.
>>>       
>> Это где происходит "поиск или инициализацию свободного воркера" ?
>> В стандартном Апаче свободный воркер сам accept()ит соединение.
>> О какой работе по инициализации и освобожению идёт речь ?
>>     
> Ну ладно, с поиском воркера проблем нет - accept-ит тот кто первый забрал мютекс, но
> инициализацию для нового соединения все равно какую-то провести надо, самому воркеру.
>
>   
>>>> Поддержка pipelined запросов к бэкенду существенно усложнит проксирование
>>>> и бессмысленна на данный момент - по умолчанию pipelining использует
>>>> только Опера. Firefox нужно специально настраивать, а MSIE, по-моему,
>>>> не поддерживает вообще.
>>>>         
>>> А при чем тут использование pipeline браузером ? Мы ж pipeline к бекенду
>>> обсуждаем. Хотя обсуждать тут особо нечего - Anton Yuzhaninov
>>> <citrin at citrin.ru> привел пример, когда использование pipeline
>>> увеличивает задержку при неудачном стечении обстоятельств.
>>>       
>> А при том что,
>> ---------
>> В случае пайплайнинга, ngnix будет проксировать каждый реквест в новом
>> соединении к бекенду?
>> ---------
>>     
> И что? Где-то требуется чтобы бекенд начинал обработку запроса строго после
> обработки предыдущих в pipeline? Nginx постал запрос, бекенд обработал -
> где проблема? Единственная проблема что ответ придется придержать пока
> не отдадутся все ответы на предыдущие запросы. Зато не надо ждать пока
> обработается первый запрос, чтобы приступить к обработке последующих
> запросов.
>
>   
>>> А вот если Опера присылает пачку pipelined-запросов, nginx их
>>> раскидывает по разным бекендам - это нормальная схема, только придется
>>> держать в буфере ответы на более поздные запросы, пока не уйдут в
>>> pipeline ответы на все предыдущие запросы - fifo. Задо задержка
>>> получения ответов может значительно снизиться, за счет паралельной
>>> генерации контента, но никогда не увеличится (разве что какой-то бекенд
>>> окажется перегружен, но тут надо менять текущю схему балансировки, я уже
>>> когда-то писал).
>>>       
>> nginx обрабатывает pipelining последовательно. И я не вижу никакого
>> смысла добавлять в обработку pipelining'а искусственный интеллект -
>> за четыре года его существования в nginx'е его поддержка со стороны
>> браузеров не изменилась (та же Опера + Файрвокс, выключенный по дефолту).
>>     
> Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в
> буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос
> отработал полностью - освобождается, иначе ждет пока его спросят об
> остатке ответа, который не поместился в буффер.
>
>   
>> А по поводу схемы балансировки по времени ответа очень хорошо сказал
>> на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются офигенно быстро".
>>     
> Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
> не понимаю что за "балансировка по времени ответа" - я вообще-то имел
> ввиду балансировку по текущей загруженности бекендов - по текущему
> кол-ву запросов в обработке бекендом. А не балансировать по кол-ву
> запросов вообще, как сейчас.
>