Persistent HTTP connections && Pipelining

[MZ]

В ср, 14/11/2007 в 15:35 +0300, Kostya Alexandrov пишет:
> Уважаемый, MZ, позвольте не согласится с Вами.
> Я вижу большое количество проблем при подобной реализации персистент 
> конекта к бекенду.
> Как раз то что вы предлагаете может просадить производительность 
> достаточно сильно на перекладывании по буферам,
перекладывать по буферам надо при любом проксировании. Отслеживать
ответы надо только при использовании pipeline браузером, чтоб отдавать
ему ответы в нужном порядке.
> отслеживании ответа и т.п. От описанных Вами проблем спасет только 
> keep-alive. pipelining имеет смысл только если
> он поддерживается бекендом.
keep-alive это и есть персистент коннект
pipeline от прокси к бекенду вреден в любом случае, используется он
браузером или нет.
pipeline используется для того чтобы не ждать пока сервер отдаст все
данные по предыдущему запросу, а сразу слать следующий, это дает выигрыш
как минимум на величину пинга от браузера к серверу. В случае
прокся-сервер это выигрыш невелик, но если прокся промахнется и направит
запрос в застопорившийся pipeline - может получиться большой проигрыш.

pipeline может быть вреден и без прокси, на броузер<->сервер, если
браузер не угадает в какой поток сделать запрос.
А вот если используется прокси с правильным pipeline, тут может быть
большой выигныш на динамическом контенте, который долго генерируется.
Хотя браузер и так не дурак, чтоб слать запросы к предположительно
динамическим страницам в один pipeline.

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