5

Azure embraces the notion of elastic scaling and I've been able to acheive this with my Worker Roles. However, when it comes to my Web Roles (e.g. MVC Apps) I am not sure what to monitor (or how) to determine when its a good time to increase (or descrease) the number of running instances. I'm assuming I need to monitor one or many Performance Counters but not sure where to start.

Can anyone recommend a best practice for assessing an MVC Web Role instances load relative to scaling decisions?

tereško
  • 58,060
  • 25
  • 98
  • 150
JoeGeeky
  • 3,746
  • 6
  • 36
  • 53

1 Answers1

4

This question is a bit open-ended, as monitoring is typically app-specific. Having said that:

Start with simple measurements that you'd look at on a local server, representing KPIs for your app. For instance: Maybe look at network utilization. This TechNet article describes performance counters collected by System Center for Windows Azure. For instance:

  • ASP.NET Applications Requests/sec
  • Network Interface Bytes
  • Received/sec
  • Network Interface Bytes Sent/sec
  • Processor % Processor Time Total
  • LogicalDisk Free Megabytes
  • LogicalDisk % Free Space
  • Memory Available Megabytes

You may also want to watch # of requests queued and request wait time.

Network utilization is interesting, since your NIC provides approx. 100Mbps per core and could end up being a bottleneck even when CPU and other resources are underutilized. You may need to scale out to more instances to handle high-bandwidth scenarios.

Also: I tend to give less importance to CPU utilization, even though it's so easy to measure (and shows up so frequently in examples). Running a CPU at near capacity is a good thing usually, since you're paying for it and might as well use as much as possible.

As far as decreasing: This needs to be handled a bit more carefully. Windows Azure compute is billed by the hour. If, say, you scale out to an extra instance at 11:50 and scale in again at 12:10, you've just incurred two cpu-hours. Also: You don't want to scale out, then take new measurements and deciding you can now scale back again (effectively creating a constant pulse of adding and decreasing instances). To make things easier, consider the Autoscaling Application Block (WASABi), found in the Enterprise Library. This has all the scale rules baked in (such as the ones I just mentioned) and is very straightforward to use.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • Adding onto David's excellent comments, also consider using auto-scaling/monitoring services like AzureWatch @ http://www.paraleap.com Using historic charts you can see which metrics from the list David mentioned are being stressed out during periods of high load - so that you can create custom scaling rules based on those – Igorek Sep 19 '12 at 02:21