Persistent HTTP connections && Pipelining

[Igor Sysoev]

On Wed, Nov 14, 2007 at 03:14:36PM +0200, MZ wrote:

> В ср, 14/11/2007 в 15:43 +0300, Igor Sysoev пишет:
> > On Wed, Nov 14, 2007 at 02:32:32PM +0200, MZ wrote:
> > 
> > > В ср, 14/11/2007 в 15:10 +0300, Igor Sysoev пишет:
> > > > > 
> > > > > > > А вот если Опера присылает пачку pipelined-запросов, nginx их
> > > > > > > раскидывает по разным бекендам - это нормальная схема, только придется
> > > > > > > держать в буфере ответы на более поздные запросы, пока не уйдут в
> > > > > > > pipeline ответы на все предыдущие запросы - fifo. Задо задержка
> > > > > > > получения ответов может значительно снизиться, за счет паралельной
> > > > > > > генерации контента, но никогда не увеличится (разве что какой-то бекенд
> > > > > > > окажется перегружен, но тут надо менять текущю схему балансировки, я уже
> > > > > > > когда-то писал).
> > > > > > 
> > > > > > nginx обрабатывает pipelining последовательно. И я не вижу никакого
> > > > > > смысла добавлять в обработку pipelining'а искусственный интеллект -
> > > > > > за четыре года его существования в nginx'е его поддержка со стороны
> > > > > > браузеров не изменилась (та же Опера + Файрвокс, выключенный по дефолту).
> > > > > Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в
> > > > > буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос
> > > > > отработал полностью - освобождается, иначе ждет пока его спросят об
> > > > > остатке ответа, который не поместился в буффер.
> > > > 
> > > > ИИ - в данном контексте - дополнительный код, реализующий функциональность.
> > > Без дополнительного кода мало где удается обойтись.
> > > Не вижу ничего в нем суперсложного, особенно по сравнению с ИИ )
> > > Зато получаемый бонус в уменьшении времени получения контента на
> > > отправленные pipelined запросы - очевиден.
> > 
> > Для 10% (или сколько там сейчас Опера занимает) запросов ?
> Я ж не настаиваю на переделках. Хотя сам оперу использую. Просто
> утверждается что pipeline к бекенду зависит от pipeline к браузеру, а я
> с этим не согласен - pipeline к бекенду вреден, а pipeline к браузеру
> полезен, но не до конца, если в том виде как сейчас.

pipeline используется в основном на картинках, а картинки лучше отдавать
локально.

> > > > > > А по поводу схемы балансировки по времени ответа очень хорошо сказал
> > > > > > на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются офигенно быстро".
> > > > > Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
> > > > > не понимаю что за "балансировка по времени ответа" - я вообще-то имел
> > > > > ввиду балансировку по текущей загруженности бекендов - по текущему
> > > > > кол-ву запросов в обработке бекендом. А не балансировать по кол-ву
> > > > > запросов вообще, как сейчас.
> > > > 
> > > > Число текущих запросов имеет близкую корреляцию со временем ответа.
> > > > Быстрое время - мало запросов - добавляем ещё.
> > > > В общем, нет однозначного способа определить, что бэкенду можно ещё добавить
> > > > запросов и при этом он не отдаст нам информационно пустую страницу,
> > > > но всю в рюшечках.
> > > Время ответа анализировать сложнее (статистику вести, в смысле), да и
> > > оно учитывает только прошлую загрузку, тогда как кол-во запросов в
> > > обработке в данный момент - текущую. Что касается пятисоток - можно
> > > ввести функциональность (опциональную) - что если бекенд отказывает в
> > > обработке запроса - попробовать отпроксировать на следующий бекенд.
> > 
> > В случае 500-го ответа nginx умеет переходить к следующему.
> > Но 500-ый ответ с точки зрения сервера может быть оформлен как 200-ый
> > с точки зрения клиента. И отдаваться очень быстро.
> Пусть даже моментально - это не играет роли если учитывать загруженность
> по кол-ву обрабатываемых запросов.

Ну вот если у нас есть два бэкенда, один из которых выдаёт быстрые
пустые 200-ые ответы, то при равномерном распределении половина ответов
будет правильная, а при распределении по нагрузке - сильно меньше половины.


-- 
Игорь Сысоев
http://sysoev.ru