Правильная схема звонков в хранилище очередей Azure в 2015 году?

Каков правильный шаблон вызова / кода для эффективной записи в хранилище очередей Azure?

Прямо сейчас псевдокод

Создайте статический класс со свойствами учетной записи StorageCredentials и CloudStorage. При запуске приложения считывать значения из конфигурационного файла только в свойства {get;}.

Создайте класс с помощью метода async Task с входным параметром типа сообщения моего приложения. Метод сериализует тип, создает новый CloudQueueMessage, новый CloudQueueClient, новую ссылку CloudQueue. Если требуется информация о конфигурации, она считывается из статического класса. Тогда мой код:

await Task.Run( ()=> theref.AddMessage(themessage).

Мне кажется, что у меня есть некоторая избыточность в коде, и я не уверен, могут ли / как соединения быть объединены в очередь, а также, если мне нужна логика повторных попыток, как и с подключением к базе данных (SQL Server и т. Д.).

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

Все идеи приветствуются.

Используя .NET 4.5.2, C #. Код выполняется в облачной службе (рабочая роль).

Спасибо.


person Snowy    schedule 23.06.2015    source источник


Ответы (2)


  • Клиентская библиотека службы хранилища Azure уже по умолчанию выполняет повторные попытки в случае ошибок службы / сети. Он будет повторять до 3 раз за операцию.
  • Вы можете изменить свой вызов на await theref.AddMessageAsync(themessage) вместо блокировки синхронного AddMessage вызова в отдельном потоке.
  • Что касается последней библиотеки, вы можете повторно использовать объект CloudQueueClient, чтобы получить новую ссылку на CloudQueue.
  • Пока вы вызываете AddMessageAsync последовательно, одно и то же соединение будет использоваться повторно, когда это возможно. Если вы вызываете его одновременно, будет создано больше подключений, вплоть до _ 6_ подключений. Итак, если вам нужен одновременный доступ к очереди, вы можете увеличить это число.
  • Отключение алгоритма Нэгла с помощью ServicePointManager.UseNagleAlgorithm < / a> также рекомендуется с учетом размера сообщений в очереди.
person Serdar Ozler    schedule 23.06.2015

Я бы кэшировал вашу ссылку CloudQueue и использовал ее повторно. Каждый раз, когда вы добавляете сообщение в очередь, этот класс создает вызов REST с помощью HttpClient. Поскольку ваши учетные данные и URI хранилища / очереди уже известны, это может сэкономить несколько циклов.

Кроме того, рекомендуется использовать AddMessageAsync вместо AddMessage.

Для справки вы можете увидеть реализацию в клиентских библиотеках хранилища здесь.

person Rick Rainey    schedule 23.06.2015