Chapter 7
Scaling, Configuring, and Monitoring Your Site
IN THIS CHAPTER:
- Understanding your options for scaling your website for performance
- Working with diagnostic logs and troubleshooting your live site
- Exploring other aspects of configuration in your Windows Azure Web Site
Not everyone can come up with that one great website idea, the one that sends you to early retirement as droves of Internet citizens sing the praises of your creation. No, the reality is that most of us will be working well past the age of 111100 (in binary); but that’s not to say we won’t have our ideas, and some may be quite good. What options do you have to host the site?
- Buy a single server out of savings and hope that at some point you can scale the hardware while dealing with growth.
- Borrow a friend’s server and live at his or her mercy when you need changes to DNS, or RAM, or database storage space.
- Rent a Virtual Machine (or VM) through a hosting provider and try to figure out how to scale horizontally down the road.
- Find a rich aunt or uncle (or angel investor) to pay up-front capital costs to put a bank of servers into commission, then hope for traffic.
While none of these are intrinsically bad ideas — and there are certainly other (possibly better) options out there — they all come with certain restrictions or the potential to make the next family gathering quite uncomfortable. Going back for more capital before you’ve repaid the initial investment can be tricky, and not all virtualization scenarios are designed to scale in both directions (i.e., when your traffic slows down again).
So how’s this for a price point? Free. All Web Sites can start in a free tier of service; then, as the expectations for performance or the success and growth of your idea dictate, you can scale out to meet the needs of your users.
Yes, folks, that’s right: Windows Azure Web Sites can make turkey dinner fun again! No more awkward moments after having the money conversation.
USING THE POWER OF THE CLOUD: SCALE
If all my neighbors on the block decided to own just one car for all ten houses, it would be so much less expensive. I would try to pitch this to them if I could come up with a way to plan a precise schedule that would work for everyone, but practical realities prevent a car from appearing exactly where you need it to be for whomever needs it, on demand. Physics is one such reality; but if you could get past those minor details and slice the use of that car up, how would it work? You would get to have a car at a fraction of the cost. If each user returned it with a full tank of gas, those who used more would pay more; and perhaps if there were times when you didn’t use it for days, you could pay even less or not at all.
Thankfully, the web is centralized and you don’t need to have the server on your premises in order to use it; and unlike a vehicle, a processor operates at billions of cycles per second and is very good at “appearing” exactly where it needs to be in an instant, which makes sharing a server much more attractive than sharing a car. You’ll still need to pay for extra scale when you need it (and there’s plenty to go around), and your usage will vary from one hour of CPU time per day all the way up to dedicated instances that you don’t have to share at all.
Finally, it’s worth mentioning that for some features of Windows Azure Web Sites you’ll need to step up at least one level from “free” to enable benefits such as using custom domain names for your website and enabling endpoint monitoring.
Understanding Levels of Scale
Regardless of the scaling mode you choose to operate under, you will enjoy similar benefits in all your applications. Your subscription entitles you to free inbound data transfers, free storage transactions from your websites, and a free 20GB MySQL database for the first 12 months of your account.
You can manipulate the scalability of your application from under the General heading on the Configure tab of your Web Site dashboard, as shown in Figure 7-1, where it can be configured to run under one of the following three modes:
- Free — This is the default scale setting for any newly created site in Windows Azure WebSites. You can host up to 10 free sites in this mode using up to 1GB of storage and a total of 60 minutes of CPU per day, per region. This mode gives you 165MB of outbound traffic per day.
- Shared — In this mode you can host up to 100 websites per region, consuming up to four hours of CPU cycles, but your bandwidth is a la carte. Don’t worry, however, as currently it would cost you only pennies if you had 10GB of traffic. With that kind of volume you’ll likely have a business model in place that affords you the $0.60 you’d have to pay!
- Reserved — When you’re configured for reserved mode on your site, you have one or more dedicated CPU instances at your disposal, and your 100 sites will be able to share 10GB of storage. As with the other options, you pay for your outbound traffic at fairly reasonable rates. Reserved pricing is appropriate for high-traffic sites and/or sites with higher processing demands.
When you move up from the free tier of hosting you are paying for part or all of a CPU and will pay hourly costs associated with that, ranging from $0.02/hour up to $0.40/hour depending on your needs. This puts the price of these configurations in a range of $15/month up to approximately $300/month for the highest available reserved CPU.
Changing the mode that your site is running under is as straightforward as clicking the button corresponding to your selection and clicking the save button in the command bar. You will be notified that changes to scale may affect the recurring charges on your subscription and then you have to confirm your intentions if you wish to do so. The changes take only a moment and your site remains running when the switch is made. You will be charged the new rate effective the moment your site flips into the new mode.
Improving Capacity
In shared and reserved mode you can choose to scale “horizontally,” meaning you can add additional instances of your website that will automatically be used in load balancing. You can have up to six instances for shared mode and up to 10 instances when you move into a reserved configuration. Figure 7-2 shows a site using 8 of the 10 instances available.
With reserved mode you can also scale “vertically” by increasing the processing power available to your websites. You can choose from Small (1 core, 1.75GB RAM), Medium (2 cores, 3.5GB RAM), and Large (4 cores, 7GB RAM) instances to help handle your increasing load. Keep in mind that these numbers will affect pricing and act as a multiplier on the base hourly rate used to compute your monthly charges.
Just drag the slider around and use the dropdown box shown in Figure 7-2 to set the overall processing capacity available to your sites. I have to mention here that this is one of the beautiful parts of working with the cloud. I have worked with several network administrators in charge of my server deployments throughout the course of my career, and I can assure you they do not appreciate being dragged around like a slider. Their dropdown boxes are also very difficult to locate.
Scaling Linked Resources
The size of your website proper — in fact, the size of all websites under your subscription — must not exceed the maximum quota for your tier of performance. Therefore, for the free sites you can divide the 1GB of space over 10 sites. For shared and reserved modes, you can split your 100 websites over 1GB or 10GB, respectively. But that’s not the only way your site can grow.
As described in Chapter 6, there are two types of manageable linked resources in Windows Azure Web Sites: databases and storage accounts. These are both mechanisms you can use to store data required or generated by your websites, and both carry monthly charges associated with use.
Storage is a linear and decreasing charge as your consumption increases. For basic storage requirements you’ll pay as little as $0.07/GB/month of storage space; in a tiered pricing model that drops down to $0.037/GB/month. When you add in features such as geo-redundant capabilities, this can be as much as $0.095/GB/month, dropping to as little as $0.055/GB/month when you hit around 10,000 TB.
For SQL Database you start with two classification options, Web and Business, which opens the door to a number of size selections:
- Web edition — 1GB or 5GB
- Business edition — 10/20/30/40/50GB, 100GB, or 150GB
Pricing for SQL Database is also tiered, costing anywhere from $10/GB/month down to $1/GB/month as your required capacity increases. Remember to keep in mind that your database does not include egress charges, so your outbound bandwidth is metered and charged separately.
CONFIGURING AND DOWNLOADING DIAGNOSTIC LOGS
Debugging a live site can be both frustrating and time consuming if you haven’t planned ahead. Beyond writing tests to ensure that you capture the obvious and prevent regression errors, you can better equip yourself by using trace statements in your code to provide information on performance or to capture the details of an error message.
Adding a trace message is very straightforward in .NET:
Trace.TraceError("Something went terribly wrong...");With that in place throughout your code base, the other thing you’ll need to do is to enable logging for your website so that you can capture application tracing. One place you can do this is through the Azure portal, located under the Application Diagnostics header on the Configure tab of your website’s dashboard, as shown in Figure 7-3.
Enabling this feature will allow application trace logs to be written to the file system of your website and enable streaming for developers who are working on a live issue.
Viewing Trace Information from Visual Studio 2012
Windows Azure Web Sites received a lot of love from the freshly released Windows Azure SDK 2.0. There is a deeper integration with the Web Sites product, and you can manage and configure your site from within Visual Studio. One of the great features is the capability to monitor the trace output from your website’s live stream. To enable these features, you need to associate your Azure subscription with Visual Studio; if you haven’t done so already, Visual Studio will walk you through the process, prompting you for your credentials and ultimately downloading the configuration required to manage your subscription remotely.
With your subscription configuration imported into Visual Studio, you can now view your Windows Azure Web Sites through the familiar Server Explorer tool window, along with your other Azure properties. When you expand the Windows Azure Web Sites item in the tree, you’ll see the list of sites you can manage from your subscription. Right-click on a website to pull up the context menu shown in Figure 7-4.
Selecting View Streaming Logs in Output Window will reveal the Output window and display the output from Windows Azure Logs for your site. As trace messages accrue on your site, you’ll see them appear in your Output window, as illustrated in Figure 7-5.
To stop streaming the trace output, right-click the site again in Server Explorer and select Stop Viewing Logs from the context menu.
Viewing the Logs from the PowerShell Console
PowerShell and the cross-platform CLI tools also get the live streaming love. In PowerShell, the command to view the live stream is as follows:
Get-AzureWebsiteLog -Name <yoursite> -TailWatching the same set of website operations that resulted in the trace messages shown in the previous section, you can see the eerily familiar output in the PowerShell console, as shown in Figure 7-6.
To detach from the live stream, press Ctrl+Break (or Ctrl+Pause, depending on your keyboard manufacturer) to cancel script execution and exit the console.
Downloading Logs via FTP
Capturing the live feed is great while you are connected, but sometimes you’ll get a report that something went wrong when you weren’t around to capture the details.
Well below the Quick Glance section on your website’s dashboard is the link to the diagnostic log FTP endpoint. You can use your deployment credentials to access the FTP directory. Application trace logs are saved to the application folder of the diagnostic log FTP root (which points to the logFiles folder of the site’s FTP root).
SETTING UP AND USING CUSTOM DOMAINS
With tens or even dozens of people flocking to your site, you’re going to want to get branding in place right away, and the allure of “yourwebsitetoendallwebsites.azurewebsites.net” isn’t quite as squeaky clean as you would like. Once you have gone through the process of registering your domain, you’ll of course want your traffic to be tied to your brand, and the next step is setting up custom domains for your Azure website. There are two pieces to this process; some configuration happens in the Azure portal and the rest occurs through the administrative interface provided by your DNS service.
This dialog spells out the items you’ll need to check off your list in order to get a custom domain working. Essentially, that checklist proceeds like this:
Working with DNS providers varies considerably from host to host, so if you’re not already familiar with your provider’s administration system for managing CNAME and A records, you’ll need to locate the appropriate documentation on their site.
WORKING WITH APPLICATION DEFAULTS
Developers have long used application settings in our web projects, simple key-value pairs that live in our web.config file and are often set specifically for a particular environment. You may already be using web.config transforms to target specific deployment targets, but the portal for Window Azure Web Sites gives you another option to set these values.
Note that values set in the portal for your application settings and connection strings will override anything that you have in your web.config file, even if you are using transforms. This is great for scenarios in which you share the source code to your website (such as open source) but don’t want others to see values that may otherwise be sensitive to your deployment, such as usernames, passwords, or application keys for third-party services.
Working with Application Settings
Settings that you have created in your web.config file will not appear in the portal on their own. If you wish to set overrides, you need to add them to the “app settings” section on your Configure tab in all their key-value glory.
These settings are available to you through whichever language you are using on your site. In .NET, you can retrieve the values by key from the WebConfigurationManager.AppSettings collection.
WebConfigurationManager.AppSettings["MySetting"]In PHP, you can use the getenv() command to extract the data:
getenv("MySetting")Node.js has a slightly different convention, as app settings appear in dot notation format off of process.env:
process.env.MySettingRemember that if you create or modify app settings in the portal, you need to click Save in the command bar to persist your values.
Setting Up Connection Strings
Connection strings fall into the same category as your application settings; and in the event that you can’t make use of publishing profiles to set your connection strings, you can use the portal to set or override these values for your application. Figure 7-8 shows the simple three-field form required to add a connection string.
Like many other configuration settings in the portal, you need to click Save in the command bar to commit your changes.
When you looked earlier at linking SQL Database resources in Chapter 6, you’ll recall that by creating a link to the database the connection string was exposed in the Quick Glance section of your website’s dashboard. You’ll also recall that this does not implicitly make your application aware of the connection string, largely because you need a name associated with the value. You can, however, copy this connection string and paste it verbatim into the preceding form along with the appropriate name that would be expected by your application.
SETTING OTHER CONFIGURATION ELEMENTS
As you deploy your application you may need to set a few specific attributes of the site that are typically done once at initial deployment and then very rarely afterwards. You can access all these elements through the Configure tab of your site’s dashboard. While these aren’t the most exciting things you’ll deal with when deploying or configuring your website, they can certainly be important should your site have specific technical requirements. This section will help you locate and control those pieces.
Setting Framework Versions
There are only two groups of options for this higher-level configuration element: your .NET version and the PHP version that you wish to run on your site, as shown in Figure 7-9. These are easy, push-button settings that can be committed to your site configuration by clicking Save in the command bar.
Talking about .NET Framework versions is one of the fastest ways to get your head spinning. For example, any version 2.0 will run on 3.0 and 3.5, both of which are based on, built from, and run on 2.0. Applications created under any of these versions are likely to run on 4.0, and therefore 4.5, which is binary compatible with 4.0.
Of course, there can be some caveats and there are definitely some exceptions to the rule, so while the default is 4.5, you can choose to run 3.5 if your situation (or dependencies) requires it.
You’ll likely turn off PHP if you don’t need it for your site, but it doesn’t do any harm to leave it on, as it’s just a script/handler mapping and doesn’t affect performance when your application is handled by a different run time, such as .NET.
There are some breaking changes between PHP 5.4 and 5.3, but you have the option to choose between the two as your needs prescribe; and if you need to support something outside of this range, the door is open for you to do so through custom handler mappings.
Adding Handler Mappings
Some folks run their own PHP build or have other modules that they would like to run in their WAWS application. You’ll need to upload these native handlers via FTP to the bin directory of your site and create the mappings in the portal. Use the interface shown in Figure 7-10 to add any references you need and then click Save in the command bar.
Keep in mind that when you specify the location of the handler, it has to be relative to the root path of your FTP directory.
Setting the Default Document
Default documents have almost gone the way of the dodo with the advent of friendly URLs and application-level routing, but a default document can still come in handy when your site is offline or for use as a landing page while you finalize your site. Another scenario is if you are building a static site from scratch or one of the many available templates on the web.
To modify the order or precedence or set which documents should be considered “default” for your website, navigate to the Configure tab in your website’s dashboard. Default documents are near the bottom of the page. Use the interface shown in Figure 7-11 to add, remove, or sort documents.
Note that in the absence of the first document in your list the web server will attempt to locate the second document, and so on. The server will work through the list to resolve any request without a document name in the URL to a directory on your server. This gives you flexibility regarding how you name your documents across your website.
SUMMARY
Windows Azure Web Sites enables you to start small and scale up as you need, from capacity and storage space to processing power and handling increased request volume on your site. If you plan to double your traffic every day, Windows Azure should be able to keep up with your growth for at least the first few exponents without much trouble at all.
As you push your application to the cloud you are now equipped to modify its configuration on the fly, keep your sensitive data private, and even track down errors more easily with a number of different tools and approaches. In addition, by combining some of this information with other concepts covered earlier in the book, you should also be able to formulate how these capabilities can help you out in automation scenarios.
Finally, if you find that you’re missing a critical component in the features of your Windows Azure Web Site, you’ll now be able to select other options or even extend the included functionality by incorporating additional functionality and configuration as required.