Роль рабочего процесса - выбор значения конфигурации

Question

У меня есть роль рабочего, которая обрабатывает элементы из очереди. Это в основном бесконечный цикл, который выталкивает элементы из очереди и асинхронно обрабатывает их.

У меня есть две настройки конфигурации (и MessageGetLimit), которые я хочу, чтобы рабочая роль была выбрана при изменении (поэтому без необходимости перезапуска).

private TimeSpan PollingInterval 
{ 
    get 
    { 
     return TimeSpan.FromSeconds(Convert.ToInt32(RoleEnvironment.GetConfigurationSettingValue("PollingIntervalSeconds"))); 
    } 
} 

private int MessageGetLimit 
{ 
    get 
    { 
     return Convert.ToInt32(RoleEnvironment.GetConfigurationSettingValue("MessageGetLimit")); 
    } 
} 

public override void Run() 
{ 
    while (true) 
    { 
     var messages = queue.GetMessages(MessageGetLimit); 

     if (messages.Count() > 0) 
     { 
      ProcessQueueMessages(messages); 
     } 
     else 
     { 
      Task.Delay(PollingInterval); 
     } 
    } 
} 

Проблема:

В часы пик, в то время как цикл может быть запущена несколько раз в секунду. Это означает, что он будет запрашивать элементы конфигурации до 100 000 раз в день.

Является ли это вредным или неэффективным?

Answer 1

Передняя ответственность, я не использовал RoleEnvironments.

В документации MDSN для GetConfigurationSettingValue указано, что конфигурация считывается с диска. http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.getconfigurationsettingvalue.aspx. Поэтому он всегда будет медленным, когда его часто называют.

Документация MSDN также показывает, что при изменении настройки происходит событие. http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changed.aspx. Вы можете использовать это событие только для перезагрузки настроек, когда они действительно изменились.

Вот один (непроверенный, не скомпилированный) подход.

private TimeSpan mPollingInterval; 
private int mMessageGetLimit; 

public override void Run() 
{ 
    // Refresh the configuration members only when they change. 
    RoleEnvironment.Changed += RoleEnvironmentChanged; 

    // Initialize them for the first time 
    RefreshRoleEnvironmentSettings(); 

    while (true) 
    { 
     var messages = queue.GetMessages(mMessageGetLimit); 

     if (messages.Count() > 0) 
     { 
      ProcessQueueMessages(messages); 
     } 
     else 
     { 
      Task.Delay(mPollingInterval); 
     } 
    } 
} 

private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e) 
{ 
    RefreshRoleEnvironmentSettings();  
} 

private void RefreshRoleEnvironmentSettings() 
{ 
    mPollingInterval = TimeSpan.FromSeconds(Convert.ToInt32(RoleEnvironment.GetConfigurationSettingValue("PollingIntervalSeconds"))); 
    mMessageGetLimit = Convert.ToInt32(RoleEnvironment.GetConfigurationSettingValue("MessageGetLimit")); 
} 

Answer 2

ответ Джона является хорошим использованием среды Изменения/Changed события для изменения настроек без перезагрузки, но я думаю, что, возможно, лучший способ для вас, чтобы использовать экспоненциальное развинчивание политика, чтобы сделать ваш опрос более эффективный. Благодаря тому, что поведение кода более разумно, вы уменьшите частоту, когда вы его настраиваете. Помните, что каждый раз, когда вы обновляете эти параметры среды, он должен быть развернут во всех экземплярах, что может занять немного времени в зависимости от того, сколько экземпляров вы используете. Кроме того, вы делаете здесь шаг, чтобы человек был вовлечен.

Вы используете очереди хранения Windows Azure, что означает, что каждый раз, когда выполняются ваши функции GetMessages (ы), он выполняет вызов службы и получает 0 или более сообщений (вплоть до вашего MessageGetLimit). Каждый раз, когда он запрашивает это, вы получите обвинение в транзакции. Теперь поймите, что транзакции действительно дешевы. Даже 100 000 транзакций в день составляют 0,01 доллара США в день. Однако не стоит недооценивать скорость цикла. :) Вы можете получить большую пропускную способность, чем это, и если у вас есть несколько экземпляров рабочей роли, это добавит (хотя все равно будет очень небольшая сумма денег по сравнению с фактическим запуском самих экземпляров).

Более эффективным путем было бы установить экспоненциальный подход к отсрочке чтения ваших сообщений с очереди. Отметьте это сообщение Маартеном на простом примере: http://www.developerfusion.com/article/120619/advanced-scenarios-with-windows-azure-queues/. Соедините задний подход с автоматическим масштабированием рабочих ролей на основе глубины очереди, и у вас будет решение, которое меньше полагается на настройки человека. Поместите минимальные и максимальные значения, например, количество экземпляров, настройте количество сообщений, которые нужно вытащить, в зависимости от того, сколько раз сообщение присутствовало в следующий раз, когда вы его запрашиваете, и т. Д. Здесь есть много вариантов, которые уменьшат ваше участие и иметь эффективную систему.

Кроме того, вы можете посмотреть очереди обслуживания Windows Azure Service Bus, поскольку они реализуют длительный опрос, поэтому при ожидании работы в очереди в результате получается намного меньше транзакций.