Home/ Questions/Q 753671
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T14:55:28+00:00

What is the best practise solution for programmaticaly changing the XML file where the

  • 0

What is the best practise solution for programmaticaly changing the XML file where the number of instances are definied ? I know that this is somehow possible with this csmanage.exe for the Windows Azure API.
How can i measure which Worker Role VMs are actually working? I asked this question on MSDN Community forums as well: http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/02ae7321-11df-45a7-95d1-bfea402c5db1

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To modify the configuration, you might want to look at the PowerShell Azure Cmdlets. This really simplifies the task. For instance, here’s a PowerShell snippet to increase the instance count of ‘WebRole1’ in Production by 1:

    $cert = Get-Item cert:\CurrentUser\My\<YourCertThumbprint>
$sub = "<YourAzureSubscriptionId>"
$servicename = '<YourAzureServiceName>'
Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub |
Get-Deployment -Slot Production |
Set-DeploymentConfiguration {$_.RolesConfiguration["WebRole1"].InstanceCount += 1}

    Now, as far as actually monitoring system load and throughput: You’ll need a combination of Azure API calls and performance counter data. For instance: you can request the number of messages currently in an Azure Queue:

    http://yourstorageaccount.queue.core.windows.net/myqueue?comp=metadata

    You can also set up your role to capture specific performance counters. For example:

     public override bool OnStart()
 {
    var diagObj= DiagnosticMonitor.GetDefaultInitialConfiguration();
    AddPerfCounter(diagObj,@"\Processor(*)\% Processor Time",60.0);
    AddPerfCounter(diagObj, @"\ASP.NET Applications(*)\Request Execution Time", 60.0);
    AddPerfCounter(diagObj,@"\ASP.NET Applications(*)\Requests Executing", 60.0);
    AddPerfCounter(diagObj, @"\ASP.NET Applications(*)\Requests/Sec", 60.0);

    //Set the service to transfer logs every minute to the storage account
    diagObj.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(1.0);

    //Start Diagnostics Monitor with the new storage account configuration
    DiagnosticMonitor.Start("DiagnosticsConnectionString",diagObj);
}

    So this code captures a few performance counters into local storage on each role instance, then every minute those values are transferred to table storage.

    The trick, now, is to retrieve those values, parse them, evaluate them, and then tweak your role instances accordingly. The Azure API will let you easily pull the perf counters from table storage. However, parsing and evaluating will take some time to build out.

    Which leads me to my suggestion that you look at the Azure Dynamic Scaling Example on the MSDN code site. This is a great sample that provides:

    • A demo line-of-business app hosting a wcf service
    • A load-generation tool that pushes messages to the service at a rate you specify
    • A load-monitoring web UI
    • A scaling engine that can either be run locally or in an Azure role.

    It’s that last item you want to take a careful look at. Based on thresholds, it compares your performance counter data, as well as queue-length data, to those thresholds. Based on the comparisons, it then scales your instances up or down accordingly.

    Even if you end up not using this engine, you can see how data is grabbed from table storage, massaged, and used for driving instance changes.

    • 0