Производительность чтения служебной шины Azure

c# azure azureservicebus

491 просмотра

1 ответ

743 Репутация автора

Я пытаюсь улучшить пропускную способность службы Windows с помощью служебной шины Azure. Что я заметил, так это то, что если у меня есть такой код.

 client.OnMessageAsync(async message =>
            {
                var timer = new Stopwatch();
                timer.Start();
                bool shouldAbandon = false;
                try
                {
                    // asynchronouse processing of messages
                    await messageProcessor.ProcessAsync(message);
                    Interlocked.Increment(ref SimpleCounter);
                    // complete if successful processing
                    await message.CompleteAsync();
                }
                catch (Exception ex)
                {
                    shouldAbandon = true;
                    Console.WriteLine(ex);
                }

                if (shouldAbandon)
                {
                    await message.AbandonAsync();
                }
                timer.Stop();
                messageTimes.Add(timer.ElapsedMilliseconds);
            },
           options);

Где варианты

OnMessageOptions options = new OnMessageOptions
            {
                MaxConcurrentCalls = maxConcurrent,
                AutoComplete = false
            };

Увеличение MaxConcurrentCalls имеет небольшой эффект после определенного числа (обычно 12-16 для того, что я делаю).

Но создание нескольких клиентов (QueueClient) с одним и тем же MaxConcurrentCalls действительно повышает производительность (почти линейно).

Итак, что я делал, так это настраивал #queueclient и maxconcurrentcalls, но мне интересно, является ли использование нескольких очередей наилучшим подходом.

Итак, мой вопрос: работает ли несколько клиентов очереди с помпами сообщений плохо или полезно для службы Windows и служебной шины Azure?

Автор: Josh Источник Размещён: 17.07.2016 10:31

Ответы (1)


1 плюс

36704 Репутация автора

Я знаю, что это действительно старое время - но я думал, что внесу свои собственные выводы.

Я наблюдаю увеличение производительности обработки очередей за счет запуска нескольких процессов на одной машине. В моем случае я использую консольные приложения, но принцип идентичен.

Я думаю, что, в конечном счете, это потому, что MaxConcurrencyзначение в конечном итоге контролирует, сколько сообщений служебная шина передаст потребителю - когда он достигает этого предела, он фактически засыпает на период времени (около 1 секунды в моем опыте), прежде чем пытаться нажмите больше сообщений вниз.

Поэтому, если у вас очень простой обработчик сообщений, вы невероятно вряд ли достигнете емкости, даже если вы установите MaxConcurrencyзначение логического ядра 2x / 3x / 4x, но обработка нескольких сообщений все равно будет очень медленной, если вы отправите больше сообщений, чем клиент настроен на обработку сразу. Запуск другого процесса с тем же самым MaxConcurrencyдает вам вдвое большую доступную емкость - даже если он находится на той же машине - но на самом деле он не дает больше энергии.

В конечном счете, правильная конфигурация будет зависеть от профиля использования процессора вашими задачами очереди. Если они работают долго и имеют тенденцию жевать процессорные циклы, то слишком большая MaxConcurrencyвероятность скорее замедлит вас, чем повысит - и масштабирование на другие машины действительно будет единственным решением.

Однако, если ваши задачи очереди «разрежены» и тратят большую часть своего времени на ожидание, то вы сможете сойти с более высоким, MaxConcurrencyчем есть логические ядра в вашем процессоре - потому что они не будут все заняты все время ,

Автор: Andras Zoltan Размещён: 07.03.2018 11:15
Вопросы из категории :
32x32