Persistent HTTP connections && Pipelining
Alexey Karagodov
karagodov at gmail.com
Wed Nov 14 17:05:47 MSK 2007
14.11.07, MZ <zuborg at advancedhosters.com> написал(а):
>
> В ср, 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-а
> кол-ву запросов в обработке бекендом. А не балансировать по
> > кол-ву
> > запросов вообще, как сейчас.
> >
> >
> > если только косвенно определить, сколько отдали запросов, сколько
> > получили, разница и будет показателем примерной загруженности
> > если чего на бекенде не случится
> Эта разница равна кол-ву запросов, которые бекенд обрабатывает в данный
> момент, верно ?
примерно так (в штатной ситуации - точно так). точную цифру может сказать
только сам бекенд, при условии, что он этим функционалом обладает
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20071114/01fc2b7b/attachment.html>
More information about the nginx-ru
mailing list