ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Persistent HTTP connections && Pipelining



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

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


 




Copyright © Lexa Software, 1996-2009.