Implementing Throttling Behavior

Retired Content

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

patterns & practices Developer Center

The Autoscaling Application Block supports two autoscaling mechanisms: instance autoscaling, whereby the block changes the number of role instances based on a collection of constraint and reactive rules, and throttling, whereby the application modifies its own behavior to change its resource utilization based on a set of reactive rules. Examples of application throttling include switching off non-essential features or gracefully degrading the UI.

Throttling behavior is implemented in your application, and is always specific to your application. As the designer or developer, you must decide what features can be temporarily switched off or how you can degrade elements of the UI to free up resources for other, more essential tasks. Administrators will create the reactive rules that detect the conditions that trigger the throttling behavior. These reactive rules are similar to the reactive rules that can change the number of role instances if you are using instance autoscaling.

For more information about how administrators configure application autoscaling reactive rules, see the topic "Defining Throttling Autoscaling Rules."

A throttling autoscaling rule communicates with your application by setting a value in your application's Microsoft Azure configuration. The following code snippet shows an example Azure service configuration file (.cscfg) that includes a custom setting, named UIMode, for use with throttling.

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="DemoService" ... >
  <Role name="DemoWebApp">
    <Instances count="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="..." />
      <Setting name="Storage.ConnectionString" value="..." />
      <Setting name="UIMode" value="Normal" />

The following code snippet from a rules file shows a sample reactive rule created by an administrator that changes the value of the UIMode setting to "Level2" when then length of a queue exceeds a threshold value. You must ensure that a setting of this name exists for the target role in the service configuration file.

  <rule name="Too many documents" enabled="true">
      <greaterOrEqual operand="DocQueueLoad" than="50"/>
      <changeSetting target="DemoWebApp" settingName="UIMode" value="Level2"/>

These two configuration steps are all that you need to be able to change the configuration setting automatically.

In your Azure application, you can add code to detect when the configuration settings are changed by the Autoscaling Application Block. In the event handler, you can add code to implement the throttling actions in your application. The following code snippet shows a sample from an Azure web role.

By default, Azure restarts the role instance when it detects a configuration change. You can prevent the role instance from restarting by overriding the Changing event handler. For more information, see "RoleEnvironment.Changing Event" on MSDN.

public class WebRole : RoleEntryPoint
    public override bool OnStart()

        RoleEnvironment.Changed += RoleEnvironmentChanged;

        return base.OnStart();

    private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
        var UIMode = RoleEnvironment.GetConfigurationSettingValue("UIMode");
        switch (UIMode)
            case "Normal":
                // Normal UI Mode


            case "Level1":
                // Level1 Throttling UI Mode


            case "Level2":
                // Level2 Throttling UI Mode



In this example, the administrator should define at least three throttling rules for the web role, one for each of the UIMode setting values.

An alternative approach is to query the configuration setting from your application code when you need to decide whether your application should perform an action.

Next Topic | Previous Topic | Home

Last built: June 7, 2012