Re: Persistent HTTP connections && Pipelining

["Alexey Karagodov" <karagodov@xxxxxxxxx>]

14.11.07, MZ <zuborg@xxxxxxxxxxxxxxxxxxx> написал(а):

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

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

непонял :)  

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

всё гораздо проще. как это сделано на моих площадках: 

нгинх отдаёт по фастцги на несколько пхп-серверов 

тайм-аут соединения - 1 с 

тайм-аут получения ответа - 20 с (скрипты очень тяжёлые на некоторых площадках, в идеале надо ставить секунды 4 конечно) 

так вот, за 5 сек не успел, 5ХХ ошибка получилась, обработали (неважно как, повторили запрос на фастцги, нарисовали красивую хтмл-ю страничку, что угодно) 

зачем тут pipelining, keep-alive и пр. красивые и умные слова 

ну как pipeline с keep-alive-ом тут помогут бекенду? если физически не способоен "держать" больше 50 юзеров (к примеру) в секунду с их безмерными хотелками 

бекенду - НИКАК. если он МРЁТ, он будет УМИРАТЬ ВСЕГДА 

тут только одно мне видется, была проблема, когда при раздаче запросов нгинх "перебирал" сервера пхп-фастцги и возникала большая куча tcp коннектов, сервер отваливался, невозможно было с ним установить новое tcp соединение 

куча коннектов возникала потому, что все сервера пхп были загружены запросами по самое небалуйся, а им приходили и приходили новые запросы 

вот тут бы pipelining между nginx и php fastcgi помог бы, но и то, ЗАЧЕМ он там? 

гораздо проще и надёжнее грамотно и красиво (а способов КУЧИ несметные) обработать ошибки 5ХХ и не заниматься извратом  

если проблема в другом, например пхп всегда в определённые границы времени вписывается, то начинается проблема с tcp стеком, ну вот хотим мы на одном сервере держать 8 к коннектов. но тут надо tcp нормально настроить (sysctl) и можно будет спокойно ждать нормальной реализации pipelining-а 

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

примерно так (в штатной ситуации - точно так). точную цифру может сказать только сам бекенд, при условии, что он этим функционалом обладает