<br><br><div><span class="gmail_quote">14.11.07, <b class="gmail_sendername">MZ</b> <<a href="mailto:zuborg@advancedhosters.com">zuborg@advancedhosters.com</a>> написал(а):</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
В ср, 14/11/2007 в 15:07 +0300, Alexey Karagodov пишет:<br><br>><br>> > А по поводу схемы балансировки по времени ответа очень<br>> хорошо сказал<br>> > на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются
<br>> офигенно быстро".<br>><br>><br>> ошибки 5ХХ наверно<br>они, только непонятно почему при балансировке по загрузке они должны<br>возникать чаще чем при балансировке по кол-ву обработанных запросов.
</blockquote><div><br class="webkit-block-placeholder"></div><div>непонял :) </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> Не присутсвовал, из контекса не понимаю про какие пятисотки
<br>> идет речь. И<br>> не понимаю что за "балансировка по времени ответа" - я<br>> вообще-то имел<br>> ввиду балансировку по текущей загруженности бекендов - по<br>> текущему
<br>><br>><br>> как Вы узнаете загруженность бекенда? Cisco CSS в нгинх вкрячить?<br>Сейчас загруженность вообще никак не узнается. Запросы шлются по<br>очереди, с учетом весов. Мое предложение состояло (и сейчас состоит, я
<br>просто давно уже об этом писал, но особого интереса оно не вызвало) в<br>том что загрузка должна определяться по текущему кол-ву запросов,<br>которые определенный бекенд обрабатывает в данный момент - чем больше<br>запросов он обрабатывает тем больше шансов что он загружен, и
<br>следовательно новый запрос надо проксировать на тот бекенд что не сильно<br>занят обработкой запросов, с учетом проставленных весов, но независимо<br>от того сколько запросов было обработано каким-либо бекендом в прошлом.
</blockquote><div><br class="webkit-block-placeholder"></div><div>всё гораздо проще. как это сделано на моих площадках: </div><div>нгинх отдаёт по фастцги на несколько пхп-серверов </div><div>тайм-аут соединения - 1 с </div>
<div>тайм-аут получения ответа - 20 с (скрипты очень тяжёлые на некоторых площадках, в идеале надо ставить секунды 4 конечно) </div><div>так вот, за 5 сек не успел, 5ХХ ошибка получилась, обработали (неважно как, повторили запрос на фастцги, нарисовали красивую хтмл-ю страничку, что угодно)
</div><div>зачем тут pipelining, keep-alive и пр. красивые и умные слова </div><div>ну как pipeline с keep-alive-ом тут помогут бекенду? если физически не способоен "держать" больше 50 юзеров (к примеру) в секунду с их безмерными хотелками
</div><div>бекенду - НИКАК. если он МРЁТ, он будет УМИРАТЬ ВСЕГДА </div><div>тут только одно мне видется, была проблема, когда при раздаче запросов нгинх "перебирал" сервера пхп-фастцги и возникала большая куча tcp коннектов, сервер отваливался, невозможно было с ним установить новое tcp соединение
</div><div>куча коннектов возникала потому, что все сервера пхп были загружены запросами по самое небалуйся, а им приходили и приходили новые запросы </div><div>вот тут бы pipelining между nginx и php fastcgi помог бы, но и то, ЗАЧЕМ он там?
</div><div>гораздо проще и надёжнее грамотно и красиво (а способов КУЧИ несметные) обработать ошибки 5ХХ и не заниматься извратом </div><div><br class="webkit-block-placeholder"></div><div>если проблема в другом, например пхп всегда в определённые границы времени вписывается, то начинается проблема с tcp стеком, ну вот хотим мы на одном сервере держать 8 к коннектов. но тут надо tcp нормально настроить (sysctl) и можно будет спокойно ждать нормальной реализации pipelining-а
</div><div><br class="webkit-block-placeholder"></div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> кол-ву запросов в обработке бекендом. А не балансировать по
<br>> кол-ву<br>> запросов вообще, как сейчас.<br>><br>><br>> если только косвенно определить, сколько отдали запросов, сколько<br>> получили, разница и будет показателем примерной загруженности
<br>> если чего на бекенде не случится<br>Эта разница равна кол-ву запросов, которые бекенд обрабатывает в данный<br>момент, верно ? </blockquote><div><br class="webkit-block-placeholder"></div><div>примерно так (в штатной ситуации - точно так). точную цифру может сказать только сам бекенд, при условии, что он этим функционалом обладает
</div><div> </div><br> </div><br>