ПРОЕКТЫ 


  АРХИВ 


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:07 +0300, Alexey Karagodov пишет:

>         
>         > А по поводу схемы балансировки по времени ответа очень
>         хорошо сказал
>         > на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются
>         офигенно быстро".
> 
> 
> ошибки 5ХХ наверно  
они, только непонятно почему при балансировке по загрузке они должны
возникать чаще чем при балансировке по кол-ву обработанных запросов.

>         Не присутсвовал, из контекса не понимаю про какие пятисотки
>         идет речь. И 
>         не понимаю что за "балансировка по времени ответа" - я
>         вообще-то имел
>         ввиду балансировку по текущей загруженности бекендов - по
>         текущему
> 
> 
> как Вы узнаете загруженность бекенда? Cisco CSS в нгинх вкрячить?
Сейчас загруженность вообще никак не узнается. Запросы шлются по
очереди, с учетом весов. Мое предложение состояло (и сейчас состоит, я
просто давно уже об этом писал, но особого интереса оно не вызвало) в
том что загрузка должна определяться по текущему кол-ву запросов,
которые определенный бекенд обрабатывает в данный момент - чем больше
запросов он обрабатывает тем больше шансов что он загружен, и
следовательно новый запрос надо проксировать на тот бекенд что не сильно
занят обработкой запросов, с учетом проставленных весов, но независимо
от того сколько запросов было обработано каким-либо бекендом в прошлом.
 

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


 




Copyright © Lexa Software, 1996-2009.