Sunday, February 13, 2011

Windows Azure Tip: Overload your Web Role

Recently, I blogged about endpoint usage when using Remote Desktop with Windows Azure 1.3. The gist was that, even though roles support up to five endpoints, Remote Desktop consumes one of those endpoints, and an additional endpoint is required for the Remote Desktop forwarder (this endpoint may be on any of your roles, so you can move it to any role definition).

To create the demo for the RDP tip, I created a simple Web Role with a handful of endpoints defined, to demonstrate the error seen when going beyond 5 total endpoints. The key detail here is that my demo was based on a Web Role. Why is this significant???

This brings me to today’s tip: Overload your Web Role.

First, a quick bit of history is in order. Prior to Windows Azure 1.3, there was an interesting limit related to Role definitions. The Worker Role supported up to 5 endpoints. Any mix of input and external endpoints was supported. Input endpoints are public-facing, while internal endpoints are only accessible by role instances in your deployment. These input and internal endpoints supported http, https, and tcp.

However, the Web Role, while also supporting 5 total endpoints, only supported two input endpoints: one http and one https. Because of this limitation, if your deployment required any additional externally-facing services (for example, a WCF endpoint ), you’d need a Web Role for the customer-facing web application, and a Worker Role for additional service hosting. When considering a live deployment taking advantage of Windows Azure’s SLA (which requires 2 instances of a role), this equates to a minimum of 4 instances: 2 Web Role instances and 2 Worker Role instances (though if your worker role is processing lower-priority background tasks, it might be ok to maintain a single instance).

With Windows Azure 1.3, the Web Role endpoint restriction no longer exists. You may now define endpoints any way you see fit, just like with a Worker Role. This is a significant enhancement, especially when building low-volume web sites. Let’s say you had a hypothetical deployment scenario with the following moving parts:

  • Customer-facing website (http port)
  • Management website (https port)
  • sftp server for file uploads (tcp port)
  • MongoDB (or other) database server (tcp port)
  • WCF service stack (tcp port)
  • Some background processing tasks that work asynchronously off an Azure queue

Let’s further assume that your application’s traffic is relatively light, and that the combining of all these services still provides an acceptable user experience . With Windows Azure 1.3, you can now run all of these moving parts within a single Web Role. This is easily configurable in the role’s property page, in the Endpoints tab:


Your minimum usage footprint is now 2 instances! And if you felt like living on the wild side and forgoing SLA peace-of-mind, you could drop this to a single instance and accept the fact that your application will have periodic downtime (for OS updates, hardware failure/recovery, etc.).


This example might seem a bit extreme, as I’m loading up  quite a bit in a single VM. If traffic spikes, I’ll need to scale out to multiple instances, which scales all of these services together. This is probably not an ideal model for a high-volume site, as you’ll want the ability to scale different parts of your system independently (for instance, scaling up your customer-facing web, while leaving your background processes scaled back).

Don’t forget about Remote Desktop: If you plan on having an RDP connection to your overloaded Web Role, restrict your Web Role to only 3 or 4 endpoints (see my Remote Desktop tip for more information about this).

Lastly: Since you’re loading up a significant number of services on a single role, you’ll want to carefully monitor performance (CPU, web page connection latency, average page time, IIS request queue length,  Azure Queue length (assuming you’re using one to control a background worker process), etc. As traffic grows, you might want to consider separating processes into different roles.