ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nginx-1.3.1



Hello!

On Tue, Jun 05, 2012 at 08:05:41PM +0400, Михаил Монашёв wrote:

> Здравствуйте, Maxim.
> 
> >> >     *) Добавление: директива least_conn в блоке upstream.
> >> 
> >> А как она взаимодействует с балансером?
> 
> > Оно и есть balancer.  Выбирает бекенд с наименьшим количеством 
> > соединений.
> 
> Никак  не  соображу, каким должен быть бэкенд, чтобы этот балансер был
> эффективнее дефолтного? Т.е. какую задачу решает этот балансер?

Имеет смысл в первую очередь тогда, когда продолжительность 
обработки запросов заметна, и при этом может заметно варьироваться 
и/или соединение является определяющим ресурсом (read: 
process-per-connection backend).  E.g. для какого-нибудь long 
polling'а - самое оно.

Ну и для обычных workload'ов с заметным разбросом по 
продолжительности обработки запросов - тоже полезно.  E.g. обычная 
раздача файлов с бекендов может выиграть, если среди файлов 
встречаются как маленькие, таки и большие (зачем лишний раз 
дёргать бекенд, отдающий dvd на 8 гиг, если у нас ещё пяток 
бекендов простаивает?).  И при неадекватной работе какого-либо 
бекенда (read: не отвечает) - на него естественным образом 
перестанут поступать запросы, что тоже явный плюс.

Я скорее затрудняюсь назвать класс задач, на котором такой 
алгоритм будет вести себя хуже, чем обычный round-robin.  Так что 
правильный вопрос скорее "почему бы не сделать так по умолчанию".

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.