Persistent HTTP connections && Pipelining

[Alexey Karagodov]

14.11.07, MZ <zuborg at advancedhosters.com> написал(а):
>
> В ср, 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'е его поддержка со стороны
> > браузеров не изменилась (та же Опера + Файрвокс, выключенный по
> дефолту).
> Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в
> буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос
> отработал полностью - освобождается, иначе ждет пока его спросят об
> остатке ответа, который не поместился в буффер.
>
> > А по поводу схемы балансировки по времени ответа очень хорошо сказал
> > на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются офигенно
> быстро".


ошибки 5ХХ наверно

Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
> не понимаю что за "балансировка по времени ответа" - я вообще-то имел
> ввиду балансировку по текущей загруженности бекендов - по текущему


как Вы узнаете загруженность бекенда? Cisco CSS в нгинх вкрячить?

кол-ву запросов в обработке бекендом. А не балансировать по кол-ву
> запросов вообще, как сейчас.


если только косвенно определить, сколько отдали запросов, сколько получили,
разница и будет показателем примерной загруженности
если чего на бекенде не случится
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20071114/10741035/attachment.html>