ПРОЕКТЫ 


  АРХИВ 


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:57:54PM +0400, Anton Yuzhaninov wrote:

> On 06/05/12 20:31, Maxim Dounin wrote:
> >Я скорее затрудняюсь назвать класс задач, на котором такой
> >алгоритм будет вести себя хуже, чем обычный round-robin.  Так что
> >правильный вопрос скорее "почему бы не сделать так по умолчанию".
> 
> 1. Большое количество "легких" запросов примерно одинаковых по
> ресурсоемкости (но несмотря на это небольшой разброс по времени
> выполнения все равно будет).
> round-robin на такой нагрузке будет примерно одинаково загружать
> бэкенды, а с least_conn скорее всего нагрузка будет менее
> равномерно, из за того, что на таких задачах текущее кол-во
> коннекций на бэкенде будет быстро скакать и постоянным будет только
> среднее.

Не думаю, что тут будет существенная разница между least_conn и 
round-robin.

С точки зрения администратора, понятно, round-robin более 
предсказуем в распределении нагрузки, и на графиках будет 
выглядеть ровнее.  А вот с точки зрения реальной работы - надо 
смотреть, вполне допускаю что least_conn будет лучше.  Особенно 
если к картине добавяться всякие нюансы в виде небольшого процента 
потерь пакетов к некоторым бекендам, например.

> Т. е. чтобы least_conn на таких нагрузках работал хорошо он
> должен будет учитывать не мгновенное число соединений, а exponential
> moving average (с таким коэффициентом, чтобы текущее значение
> вносило больший вклад в среднее, чем прошлые значения).

Так least_conn как раз будет заниматься тем, что приводить 
количество соединений к среднему.

> 2. А как реализован least_conn? Все воркеры пишут в некий участок
> общей памяти при открытии соединения на бэкенд и её закрытии? В
> таком случае использование least_conn должно немного замедлять
> работу на серверах с большим количеством CPU, поскольку после
> модификации участка памяти, используемого одновременно в нескольких
> процессах требуется синхронизация кэшей между разными CPU (хотя
> возможно это пренебрежимо по сравнению с другими причинами по
> которым CPU вынужден простаивать).

Нет, там per-worker счётчики.  Выбор бекенда чуть дороже, но не 
настолько, чтобы об этом всерьёз думать.

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.