On Mon, 22 Jan 2007 20:23:27 +0300
Anton Yuzhaninov <citrin@xxxxxxxxx> wrote:
Hello Mykola,
MZ> Проблема не в кол-ве серверов, а в том что если один из них вылетает,
MZ> на остальные нагрузка не пойдет в течении таймаута коннекта, пока nginx
MZ> не убедится, что установить соединение к вылетевшему серверу не удастся.
Если есть два бэкенда и один из них упал, то половина запросов будет
по прежнему идти на работающий бэкенд, а половина будет висеть в
ожидании таймаута на коннект. Его бэкендов больше одного, то его имеет
смысл делать небольшим - от 3 до 5 секунд.
Все не так. Если есть несколько бекендов, запросы распределяются
поровну, в режиме round-robin. Если один из них упал -
nginx в течении timeout пытается к нему присоединиться чтобы форварднуть
запрос, после истечения таймаута сервер помечается как down и все
запросы посылаются на рабочий (е) бекенды, но в течении этого таймаута,
пока nginx пытается к нему коннектиться, новые запросы вообще никуда не
форвардятся - round-robin сему виной. Потом nginx ждет этот же таймаут и
опять начинает пытаться подключиться к лежащему бекенду и все
повторяется.
Там неверно сформулировано. Фраза
"время, в течение которого должно произойти заданное число неудачных
попыток работы с сервером для того, чтобы сервер считался неработающим"
означает, что не то, что при настройках
max_fails=3 fail_timeout=30s;
nginx будет пытаться 30 секунд долбиться в упавший сервер, послав, например,
50 запросов.
Она означает, что допустим, у нас есть 2 запроса в секунду, один
из которыйх попадает на упавший бэкенд. Если у него стоит
"proxy_connect_timeout 5s", то через 7 (5 + 1 + 1 = 3 неудачи) секунд,
этот бэкенд будет помечен как упавший. И в течение 30 секунд к нему
не будет новых обращений. По истечении 30 секунд, 3 неудачи забываются
и всё по новой.
Надо будет переформулировать.
Но, в целом, согласен, схему балансировки нужно дорабатывать.
Игорь Сысоев
