Сервисная шина Azure - сокращение времени прохождения туда и обратно

Мы проверяем служебную шину Azure, чтобы использовать ее в качестве локальной служебной шины. Мы тестируем время прохождения туда и обратно, и кажется, что оно колеблется от 10 мс до 2000 мс. В среднем это около 100-200 мс. Кажется, что время прогрева увеличивается с 2 секунд до 200 мс при более высокой нагрузке.

Есть ли способ уменьшить среднее время поездки туда и обратно?

Помогает ли использование премиум-уровня? -> (Изменить: не помогло. С 1 блоком сообщений среднее значение было хуже с премиум-уровнем)

Наша установка:

  • Потребитель (ПК №1)
  • Производитель (ПК №2) (примечание: эти два компьютера находятся в одной локальной сети)

  • Сервисная шина Azure (фактически на лазурном)

  • Примечание / забавный факт: расстояние до центра обработки данных Microsoft 1500 км. Скорость света составляет ~ 10 мс туда и обратно.

Тест 1:

  • Количество сообщений: 1000 в минуту
  • MaxConcurrentCalls: 1
  • Операция: получение и удаление сообщения
  • Количество предварительной выборки: 0
  • Начать средн. 1-2 с
  • Конец ср. 100-200 мс
  • Вывод: Вставить ссылку

Пример вывода:

20; 2017-12-07T11:41:48.5134157+01:00; 2017-12-07T11:41:48.7781795+01:00; 264,7638
3; 2017-12-07T11:41:47.4827021+01:00; 2017-12-07T11:41:48.8378167+01:00; 1355,1146
14; 2017-12-07T11:41:48.1491488+01:00; 2017-12-07T11:41:48.8950421+01:00; 745,8933
0; 2017-12-07T11:41:47.2250519+01:00; 2017-12-07T11:41:48.9518713+01:00; 1726,8194

Тест 2:

  • Количество сообщений: 1000 в минуту
  • MaxConcurrentCalls: 1000
  • Операция: получение и удаление сообщения
  • Количество предварительной выборки: 0
  • Начать средн. 1-2 с
  • Конец ср. 100-200 мс (примечание: со всплесками до 20 секунд)
  • Вывод: Вставить ссылку

Пример вывода:

4; 2017-12-07T11:43:43.5735023+01:00; 2017-12-07T11:43:44.7905668+01:00; 1217,0645
8; 2017-12-07T11:43:43.8166842+01:00; 2017-12-07T11:43:44.8424773+01:00; 1025,7931
11; 2017-12-07T11:43:43.9990189+01:00; 2017-12-07T11:43:44.8989094+01:00; 899,8905
10; 2017-12-07T11:43:43.9383692+01:00; 2017-12-07T11:43:44.9553891+01:00; 1017,0199

Тест 3:

  • Количество сообщений: 1000 в минуту
  • MaxConcurrentCalls: 1000
  • Операция: получение и удаление сообщения
  • Количество предварительной выборки: 1000
  • Начать средн. 1-2 с (разминка значительно снижена)
  • Конец ср. ~ 100 мс (примечание: с пиками до 4,5 секунд, значительно меньше пиков)
  • Вывод: Вставить ссылку

Пример вывода:

11; 2017-12-07T11:54:16.8149682+01:00; 2017-12-07T11:54:17.6029464+01:00; 787,9782
14; 2017-12-07T11:54:16.9967915+01:00; 2017-12-07T11:54:17.6709669+01:00; 674,1754
0; 2017-12-07T11:54:16.0599312+01:00; 2017-12-07T11:54:17.6720080+01:00; 1612,0768
15; 2017-12-07T11:54:17.0578415+01:00; 2017-12-07T11:54:17.6724941+01:00; 614,6526

=========================

Клиент:

using System;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.ServiceBus;

namespace Sticos.ServiceBus.Client
{
    public class ServiceBusClient
    {
        private readonly string _connectionstring;
        private readonly string _topic;
        private readonly TopicClient _topicClient;

        public ServiceBusClient(string connectionstring, string topic)
        {
            _connectionstring = connectionstring ?? throw new ArgumentNullException(nameof(connectionstring));
            _topic = topic ?? throw new ArgumentNullException(nameof(topic));
            _topicClient = new TopicClient(_connectionstring, _topic);
        }

        public async Task SendAsync(string message)
        {
            await _topicClient.SendAsync(
                new Message()
                {
                    Body = Encoding.UTF8.GetBytes(message + ";" + DateTime.Now.ToString())
                });
        }
    }
}

Режиссер:

using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Sticos.ServiceBus.Client.Test
{
    [TestClass]
    public class ServiceBusClientTest
    {
        [TestMethod]
        public void Producer()
        {
            var serviceBus = new ServiceBusClient("[connectionstring]", "[topic]");

            var producer = Task.Factory.StartNew(() =>
            {
                var tasks = new Task[1000];
                for (int i = 0; i < 1000; i++)
                {
                    tasks[i] = serviceBus.SendAsync($"{i};{DateTime.Now.ToString("o")}");
                    Thread.Sleep(60);
                }

                Task.WaitAll(tasks);
            });

            Task.WaitAll(producer);
        }
    }
}

person Stian Standahl    schedule 07.12.2017    source источник
comment
Я не мог не заметить, что вы используете один и тот же клиент для обработки всех 1000 сообщений. Это означает, что для передачи всех этих сообщений используется одно соединение. У соединения есть определенная точка, в которой оно не будет отправлять больше, чем может (как водопроводная труба). Решение состоит в том, чтобы иметь несколько клиентов, созданных на нескольких фабриках. Увеличение параллелизма до 100 не кажется изобретательным, если у вас только одно соединение.   -  person Sean Feldman    schedule 08.12.2017
comment
Проблема не в количестве отправленных сообщений. Это время отправки одного сообщения от производителя (ПК №2) потребителю (ПК №1). Сервисная шина отлично справилась с нагрузкой в ​​10 000 сообщений в минуту. Время доставки каждого сообщения к месту назначения составляло в среднем 100-200 мс. Мы хотим, чтобы это время было меньше.   -  person Stian Standahl    schedule 08.12.2017


Ответы (2)


Уровень служебной шины премиум-класса обеспечивает стабильную производительность, поскольку в вашем пространстве имен будут выделенные ресурсы, на которые не могут повлиять шумные соседи. На стандартном уровне производительность колеблется в зависимости от общей нагрузки на службу, поскольку ваши очереди / темы совместно используют ресурсы с очередями / темами других клиентов.

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

Но я думаю, что повышение пропускной способности приема сообщений также снизит среднее время, необходимое для того, чтобы сообщение достигло потребителя. кстати, вы не вставляли сюда код для потребителя. Я бы посоветовал вам попробовать несколько улучшений. Пакетная отправка действительно помогает производительности. Вместо того, чтобы отправлять одно сообщение для каждого вызова отправки, отправляйте пакеты по 10 или 100 секунд в зависимости от размера сообщения. Также на ресивере попробуйте использовать режим RECEIVEANDDELETE, если шаблон PEEKLOCK / COMPLETE для вас не так важен. А использование слишком большого количества одновременных вызовов означает использование слишком большого количества потоков. Попробуйте настроить максимальное количество одновременных вызовов и значения счетчика предварительной выборки и посмотрите, как изменится пропускная способность.

Также AMQP обеспечивает лучшую производительность по NetMessaging или Http. Проверьте конфигурацию вашего клиента для используемого протокола и измените его на AMQP.

Как предполагали другие ответы, большее количество подключений определенно улучшит пропускную способность. Просто используйте больше отправителей и больше получателей.

person Vijay    schedule 08.12.2017
comment
Я попробовал премиум-аккаунт с 1 MU и обнаружил, что время, затраченное на поездку туда и обратно, не подходит для моего использования. Мой код в основном находится в помещении, а не в Azure, поэтому я решил использовать для начала локальный Rabbit MQ. У Rabbit MQ было около 1-5 мс туда и обратно. В вопросе я вычислил время, которое потребовалось свету (по прямой), чтобы добраться из Дублина до моего местоположения, и время туда и обратно составило 10 мс. Добавив несколько переходов к маршрутизатору, мы, вероятно, сможем удвоить или утроить это количество. Со временем прохождения туда и обратно 40-50 мс я, вероятно, мог бы использовать Azure. Но 200 мс - это слишком много. - person Stian Standahl; 11.12.2017
comment
Я, вероятно, мог бы заплатить за больше MU, но это будет дорого стоить по сравнению с размещением на некоторых серверах, которые я арендую. Есть ли у вас альтернативы? Может быть, какими-нибудь другими способами мы могли бы это сделать? Я быстро прочитал кое-что об Azure Stack. Есть ли у этого полноценная служебная шина? - person Stian Standahl; 11.12.2017

Поэтому, если вы используете служебную шину изнутри, есть несколько вещей, которые можно сделать. Вы можете, например, выполнить развертывание в регионе Azure, который находится ближе всего к вашему собственному центру обработки данных. Вы можете проверить время возврата из вашего DC в Azure DC и измерить задержку. Еще одна вещь, которую вы могли бы оценить, - это использование экспресс-маршрута для минимизации задержки. Не могли бы вы отправить запрос в службу поддержки? Мы можем заглянуть в бэкэнд и посмотреть, сможем ли мы помочь вам в дальнейшем в этом контексте.

person Christian Wolf    schedule 19.12.2017