Speed Up Your Web Site with Microsoft Azure BLOBs

by Brian Prince

Learn how to leverage BLOBs in your application. Read along as we look at the simplest of those scenarios, simply hosting your public files in a better place than your server.


We have all been there before. You have a web application that runs in your data center, and the load the website is generating is increasing. You need to buy more servers and increase your bandwidth to the Internet as well. Every year you find yourself back in the same place, adding servers, increasing bandwidth. The costs of your simple little website keep expanding. In this article we are going to explore how you can leverage Microsoft Azure to ease this burden. You will be able to serve more visitors with the same servers you have today, give them a speedier experience, and reduce your bandwidth usage.

The typical web server farm looks like the following diagram. You have a four web servers (or more) sitting behind a load balancer, receiving requests from the Internet. Your server is handling several jobs. It has to process user requests, fetch data, bind that data to the ASPX view (web forms or MVC) and serve the resulting HTML back. That HTML has URLs to resources your server is hosting, namely images and JavaScript. Serving out this HTML and static resources takes up bandwidth as well. Another challenge is that your users around the world have a poor experience waiting for your static media to be sent from under your desk all the way to Japan.

Figure 1

As traffic to your site grows, so does the demand on your servers and bandwidth. There is a very simple solution to help you out of this ever increasing need for resources. That solutions is cloud computing with Microsoft Azure.

You may not want to or be prepared to move your whole application to the cloud. Perhaps moving the application to the cloud doesn't make sense in your scenario. The great thing about Azure is that it is meant to be used in pieces; it isn't an all or nothing scenario.

Imagine keeping your application wherever it is today, under your desk, in your datacenter, or at a hosting provider. All we are going to do is move half of our web server's responsibilities to the cloud. We are going to move all of our static media to Micrsoft Azure, and have it hosted there.

How can Microsoft Azure help?

Microsoft Azure has three types of storage in the cloud. They are BLOBs, queues and tables. BLOB is an acronym that stands for Binary Large Object, and you might have had reason to work with BLOBs in a relational database like SQL Server. Your experience as a developer was likely terrifying. BLOBs are hard to use in a database, since databases aren't really made for storing large unstructured pieces of data.

Don't worry about BLOBs in Microsoft Azure. In Azure they are simply a file system in the cloud. There are a lot of ways to leverage BLOBs in your application, and in this article we are going to look at the simplest of those scenarios, simply hosting you public files in a better place than your server.

Hosting your static media in Microsoft Azure can gain you a lot of benefits. You will quite easily remove a lot of load from your servers. This allows those servers to host even more simultaneous users. This puts off the day when you have to add more servers to your web site. You should track the work your web servers are performing; I think you will see a big spike in the amount of users you can host on one of your servers if they no longer have to respond to the static media requests.

Another benefit is that since the static media is being hosted and served from Microsoft Azure, the client is downloading those files over Microsoft's bandwidth and not your own. This has two results. The first is that you will have reduced the impact to your own bandwidth. Your web server will still be sending the HTML to the user, but the URLs that point the graphics and JavaScript on your site will point to your BLOBs in Azure, not to files on your server. Their browser will then ask Azure for the images, and not yours. This will lessen that amount of bandwidth that you will need, since most of the bandwidth used by a web site is in transferring the static files, and not the HTML. The user will also not be restricted by the amount of bandwidth you have, since the Azure datacenters have massive pipes to the Internet.

The second benefit is that your users will be able to download more files at the same time. Each browser is limited to downloading only two files per host name. This is an old networking standard that doesn't really apply to today's modern networks, but it is still enforced. One cheat many users do is to change the registry of their Windows machine to download more than two files at a time from each host. You can't rely on your users really doing this to improve the performance of your site.

Many sites now host their static media on the same servers as they used to, but under different web site names to speed up the downloading by browsers. Take a look at some HTML, you might find that all the images on foo.com come from images.foo.com, and that all the JavaScript comes from script.foo.com. These sites do this to speed up their user's experience. We are going to do the same thing, but move those files to the cloud instead of to another site on the same server.

Figure 2

Moving Our Files to the Cloud

So how do we move our files to the cloud? It is really quite simple, and will require very little change in your code.

The first few steps require that you have a Microsoft Azure account. Go to http://www.azure.com and sign up for an account. If you have an MSDN account you can activate a benefit that will give you a limited amount of free time and space every month. You will need to provide a credit card, but the charges we are talking about here are fairly minimal. To store files in Azure costs $0.15/GB/month of data stored. That is pretty small. You will also have to pay for bandwidth, but you would have to do that anyway, and Microsoft's bandwidth is likely cheaper than what you are paying your current hosting provider.

Once you have an account created you will need to create a storage account. Each Microsoft Azure account can have many storage accounts. This lets you easily organize your files into groups by customer, site, or any other category you can think of.

Once you have logged into your Azure account, click 'New Service' in the top right.

Figure 3

Choose to Create a Storage Account.

Figure 4

Then you will need to provide as simple name for this storage account. I chose to enter 'My Site's pictures.' Once you have done that, click 'Next.'

Figure 5

Now you will need to enter a host name for your storage account. This must be DNS friendly, and must be unique. This will be how the public accesses your files. I entered sushipictures. You will also have to tell Azure where to store your data. I picked North Central US. Once you have done that, click 'Create'. This will setup your account and provide you wilth all of the account information you need.

Figure 6

Azure will create access keys for you to securely access your data. The screen will list out all of the information you provided to create the storage account. Do not ever share your access keys with anyone; this would be like giving them the administrator password to your data.

Figure 7

Uploading Your Data to Microsoft Azure

Now that you have a storage account in the cloud you will need to move your files. There are many tools available to do this. Some are commercial, and some are available on http://CodePlex.com. A web based tool that I use is www.myAzureStorage.com. You will have to configure it with your storage access key (the one I told you not to share with anyone). This web app (or any application for that matter) needs this key to access your storage account on your behalf.

Figure 8

Once you are logged in, click the 'blobs' menu item at the top, and then select to create a container. You will need to give the container a name. The name I am using is 'products.'

Figure 9

By default each container in your storage account is marked private. Any access will require the storage access key. Since we want to share the contents of our container with the world, to whomever comes to our site, we need to mark it 'container level' public.

Figure 10

Container level will let anyone read and list the contents of the container. The other option would be blob level. Blob level will let anyone read a provided file, but they won't be able to browse or list the contents of the container itself. Now that we have created a container in our storage account, and marked it as public, we can start uploading our files. Click on the action menu item and choose add blob. This will let you upload files. This tool only lets you upload one file at a time. Many of the other tools will let you upload whole folders of files.

In our example, the storage account we created had the name sushipictures. If we put a file named bigtuna.jpg in that container then the URL to that image will http://sushipictures.blob.core.windows.net/products/bigtuna.jpg. Notice that the host name is the unique DNS name we provided while we were creating our storage account, and the folder name 'products' is the name of our container.

Your website might have a hierarchy of files that you need to support. For example, under the products folder we might have two subfolders, 'fresh' and 'nearlyfresh'. Containers do not support sub-folders like you might imagine. You cannot create a container within a container to achieve this effect. What you need to do is name your files so that the 'sub-folder' name is in the name of the file. If I wanted the picture 'oldtuna.jpg' to be in the 'nearlyfresh' subfolder, I would give it the name 'nearlyfresh/oldtuna.jpg' and place it in my products container. Its URL would then be http://sushipictures.blob.core.windows.net/products/nearlyfresh/oldtuna.jpg. The name becomes the path we want it to have. You can now go ahead and create a separate storage account (or just a separate container) for your JavaScript files. Perhaps sushijavascript.blob.core.windows.net/scripts. This would give your users browsers even more speed by giving them a third host name to download their files from.

The last step would be to change your website to produce URLs pointing the files in the cloud instead of the local server. Where your image URL might be http://www.dayoldsushionline.com/pictures/bigtuna.jpg, you will change it to http://sushipictures.blob.core.windows.net/products/bigtuna.jpg. How you do this might depend on how you have written your site. Some URLs are hardcoded into the ASPX files. In this case you could use global search and replace on your ASPX files. Sometimes the image locations are stored in a database. In this case you could use an SQL command to update your database. The third option I see a lot is a web.config setting that sets the based image path to a specific folder. In this case you should be able to easily change your configuration.

To see this in action, take a look at http://www.windowsazurebootcamp.com/materials. Hover over a link to one of the downloads. You notice that the URL is not windowsazurebootcamp.com/materials/bootcampmaterials.zip but abcdata.blob.core.windows.net/downloadablematerials/Windows%20Azure%20Boot%20Camp%20Materials.zip.

Making this change on the website only required us to upload the files, and change our HTML to point to the new file location. Nothing could be simpler.

Leveraging the Microsoft Azure CDN

There is a third benefit that we can leverage with Microsoft Azure BLOBs and that is to use the Azure CDN. CDN stands for Content Delivery Network. Imagine a user in Japan browsing your site. Since you chose to host your Azure data in North Central US (effectively Chicago) then their browser will have to download that file from across the oceanic lines. This is not speedy. Instead, by turning on the CDN feature on your storage account, any public containers are automatically replicated across 19 servers across the world.

These 19 servers will replicate you data to servers that are geographically closer to your users. When you sign up to use the CDN you stop using the normal URL for your BLOBs, and instead will use a special URL for the CDN. When the user's browser asks for the file at this special URL geographically aware DNS servers will kick in, and route the request to the best cache server. You do pay a little extra to use the CDN, but if you have a global customer base it is worth every penny. Your site will suddenly become much faster to your users.

But I don't like sushipictures.blob.core.windows.net

It is very possible that you will not want the URLs to your files in the cloud to end in the blob.core.windows.net domain name. This is understandable. You want that big company look and feel. This isn't a problem. On the Azure portal you can configure your DNS servers to cover over the windows.net domain name with your own.

These are called custom domains. At the bottom of the storage account screen on the portal you can click 'manage.' This will let you configure a custom domain name to overlay on top of the windows.net domain name, hiding it from your customers. You will need to own this custom domain, and have it hosted on your own DNS servers.


Cloud computing isn't an all or nothing situation. You can pick and choose from the features that Microsoft Azure provides to really solve the pain points you are having. Not every site needs an elastic computing platform, my blog sure doesn't. In this article we looked at how a site can save a lot of money, and improve the user's experience, just by moving your static media (images, movies, and scripts) to the cloud. This takes a load of off your servers, helps your users download quicker, and potentially even gives global users a faster experience. We managed to do this with almost no change to our code, which means it is low risk.

Related Articles

This article was originally published on Thursday Jul 1st 2010
Mobile Site | Full Site