Поделиться через


Tuning the Autoscaling Application Block

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

On this page:
Summary of Key Configuration Settings | Configuring the Stabilizer | Configuring the Activity Scheduler | Running Multiple Instances of the Autoscaling Application Block | Tracking Service Management Requests

This topic describes how you can tune the behavior of the Autoscaling Application Block to optimize its performance and resource usage.

Summary of Key Configuration Settings

The following table lists the key configuration values that you can change that impact the overall performance of the Autoscaling Application Block.

For more information about how to change these configuration values, see the topic "Entering Configuration Information."

Setting

Notes

Rule evaluation rate

This value controls how frequently the block evaluates the set of autoscaling rules and performs scaling operations.

The default value is 4 minutes. If you set this to a longer period, the block may take longer to respond to changes, but this will reduce the amount of work that the block performs.

Rules store change monitoring rate

This value controls how frequently the block checks for changes to the autoscaling rule set in the rules store.

Its default value is 30 seconds; that means the block will detect changes to the rules store within a reasonable time without having a negative impact on performance.

Service information store change monitoring rate

This value controls how frequently the block checks for changes to the service information store.

Its default value is 30 seconds that means the block will detect changes to the service information store within a reasonable time without a negative impact on performance.

Service management request tracking rate

This value controls how frequently the block checks the status of previously submitted scaling operations. The block will check the list of service management requests on the queue to see which ones have completed.

If the value of this setting is too large, the block may not be able to check all of the outstanding requests. The default value is 5 minutes, which means that the block should be able to check all of the outstanding requests without having a negative impact on performance.

Configuring the Stabilizer

The stabilizer component is designed to minimize the number of scaling operations that the block performs by allowing you to specify cool down periods. A cool down period is the time after the block has performed a scaling operation during which the block will not perform any further scaling operations. This helps to prevent oscillations whereby the block repeatedly scales a role up and down. It also gives your application a chance to "settle down" with the new number of role instances.

You can adjust how aggressively the block will scale up and scale down roles by configuring the cool down scale up and cool down scale down durations. You can set default values for all roles and scale groups, or provide specific values for individual roles and scale groups. These values are part of the service information for your application that the block stores. For example, if the scale up cool down period is set to 20 minutes for a role, then after the instance count for the role has changed, the block will not perform any scale up operations on the role for the next 20 minutes.

You can also use the stabilizer to manage your costs. Microsoft Azure bills for role instances by the clock hour. If you start a new instance at five minutes past the hour or 50 minutes past the hour, you are billed for a complete hour. Similarly, if you terminate a role instance at five minutes past the hour or 50 minutes past the hour, you are still billed for a complete hour of usage.

You can configure the stabilizer to only scale up near the beginning of the hour and only scale down near the end of the hour. This helps you to maximize the usage of your running role instances. For example, you can specify that scale up operations should only happen in the first 15 minutes of the hour, and that scale down operations should only happen in the last 10 minutes of the hour. If the stabilizer determines that it should not perform a scaling operation, it does not queue the operation, it drops it.

Note

The stabilizer evaluates whether it should perform the scaling operation after reconciling any conflicting rules.

For more information about the configuration settings, see the topic "Service Information Schema Description."

For sample configuration settings, see the section "Configuring the Stabilizer" in chapter "Autoscaling and Microsoft Azure" of the Developer's Guide.

Configuring the Activity Scheduler

The activity scheduler is responsible for running all of the activities that the Autoscaling Application Block needs to perform its autoscaling function. These activities include data point collection, rule evaluation, and service tracking.

You can configure the rates at which the block performs these activities. In general, the more frequently the block performs the activities, the more responsive it will be at the cost of greater resource usage.

The rates are specified in the block's configuration settings.

To configure the rule evaluation rate, the rules store monitoring rate, the service information store monitoring rate, and the service management request tracker tracking rate, see the topic "Entering Configuration Information."

Running Multiple Instances of the Autoscaling Application Block

If your application has a large number of roles and a large number of autoscaling rules, you may decide to run multiple instances of the Autoscaling Application Block. If this is the case, you must ensure that at any time, only one instance of the block is evaluating the autoscaling rules, otherwise you may submit multiple, duplicate scaling requests.

If you host the block in Azure, the block provides a mechanism based on blob leases to manage this automatically. You must enable blob execution leases in the block's configuration by setting the UseBlobExecutionLease option to true. For more information, see the topic "Entering Configuration Information."

If you are only running a single instance of the Autoscaling Application Block, you can reduce the overhead of using the block by setting the UseBlobExecutionLease option to false.

Tracking Service Management Requests

The TrackServiceManagementRequests setting in the block's configuration controls whether the block tracks the scaling operations that it initiates and logs their success or failure. By default, this option is configured to false because of the overhead of the additional service management API calls that the block needs to make to track the completion of the scaling operations. If this option is set to true, then in addition to the service management API calls, the block will use an Azure queue to track the scaling requests and write log messages with the details of the success or failure of the scaling operations.

Setting this option to true will give you more information about the behavior of the Autoscaling Application Block and provide additional troubleshooting data.

Note

The block does not check in advance of making a scaling request whether it would cause the maximum number of cores allowed by the subscription to be exceeded.

Next Topic | Previous Topic | Home

Last built: June 7, 2012