Persistent HTTP connections && Pipelining

[MZ]

В ср, 14/11/2007 в 15:07 +0300, Alexey Karagodov пишет:

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

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

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