ПРОЕКТЫ 


  АРХИВ 


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



On Wed, Nov 14, 2007 at 04:02:50PM +0200, MZ wrote:

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

В общем, такой метод распределения вполне может появится в nginx'е,
но только не стоит его рассматривать как панацею, поскольку возможны
описанные выше ситуации, когда такой метод только ухудшает систему.


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



 




Copyright © Lexa Software, 1996-2009.