big bond wrote:
> Да, согласен, стормозил про апстрим.
> Ваши советы весьма разумны, более того, сейчас все приблизительно так и
> сделано, только как я сказал, помимо простого раунд-робина текущий
> балансировщик умеет динамически менять коэффициент веса бекенда,
> основываясь на задержке отклика GET-запроса к каждому из них. Я всего
> лишь спросил, может ли энджи так, или нет, простая функция ведь. Если
> нет, то как говорится "будем искать" того, кто умеет. Убеждать меня в
> том, что это бессмысленно - бессмысленно ), я ищу то, что ищу, не более.


В таком случае можно было обойтись документацией.

Я вот убей бог не понимаю, почему, если есть число "А" приложений
которые нормально обслуживаются в пиках числом "Б" бекендами, нужно это
"А" раскладывать на составляющие и раздавать на разные бекенды. Я бы
понял, если бы бы бекенды были разные - "В" умеет приложение "Ц", а "Г"
- нет, но вы же говорите, что даже тяжелое приложение умеет работать на
всех бекендах. Не... не улавливаю логику. Но если уж хотите, можно
сделать так.
На "тяжелых" бекендах число процессов жестко лимитировано (не более, чем
бекенд может без проблем выполнять при пиковых запросах). Таймаут -
время ожидания бекенда. "Легкие" бекенды - как бакапные. В этом случае,
правда, будет логика "1-й тяжелый, 2-й тяжелый, 3-й тяжелый, бакапный
легкий", что не очень хорошо... но тут уже можно что-то и попатчить.


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru