Composite C1 Blog

Read the latest Blogs from Composite. Also sign up for our Monthly
Newsletter or follow us on Facebook if you want to be the first to know?

Geo DNS and Windows Azure making your CMS faster

17 June 2011 : Marcus Wendt

Imagine a setup with 6 web servers, load balancing traffic. Two servers in Europe, two in North America and two in South East Asia – all three groups running with a 99.99% uptime guarantee. Using Geo DNS features, visitors are directed to the nearest server, ensuring optimal response times. If you think this setup is advanced and expensive, make a price guess and read on – you are in for a small chock.

The task to solve

First a little background: When you launch your C1 Console you are greeted with a start screen containing recent news, helpful links and user tweets about Composite C1. This is loaded from one of our servers, ensuring the content is up to date. Until recently the content have been server from a web server running in Denmark (that's where we come from) and if have been sitting far away from Denmark the start screen load time could be affected. If the latency is above a certain threshold (500 ms maximum for a completed http request), the start screen content will be skipped entirely to ensure our users are not blocked from starting their content management tool.

To make sure that the C1 Console start screen loads and it loads fast no matter where you are sitting, we looked around for a solution which would fit our wallet (we do open source software and have no investors) and would enable us to serve people well across the globe.

What was on the shelve

Obviously we maintain the C1 Console start screen content in our own CMS – Composite C1 - and with the existing investment we have done in enabling our CMS to run on Windows Azure we have different ways to deploy and maintain content on this platform. Windows Azure has data centers placed around the globe which make it a perfect fit for serving content to different parts of the world.

Geo DNS

DNS turns a host name like www.composite.net into an IP number and geo based DNS will give different IP numbers depending on the geographical location of the entity querying for the IP. This means that you can point visitors from Australia to a server running in South East Asia and Canadians to a North American one.

There are different geo DNS service providers – some are priced at $600 per month, some probably more while at least one offer geo DNS for free. We chose the last one and so far we are very happy with them, you can find them at http://www.geoscaling.com/.

This map show how we configured the DNS - we used a latitude and longitude based feature, but geoscaling lets you resolve IP in a lot of different ways.

If you visit http://c1console.composite.net/ you will be sent to one of the three locations shown below, depending on which one is closest:

The Composite C1 and Azure setup

One of the ways you can deploy Composite C1 on Windows Azure is shown in the diagram below – you push your website files to the Azure blob storage and then deploy any number of web roles to any number of geographical locations. The Azure web role package you deploy is a standard package that you configure with a blob storage connection string. When deployed web roles will pull down the website content from the blob and when loaded start serving web requests.

We have a local Composite C1 running where we can do changes to content, design, data schemas, code and install C1 Packages and new versions of the CMS. When we have something we wish to share with the world a button in the CMS will sync any changes made to the blob storage.

A few times a minute the web roles will check the blob store for updates and - if changes are found –download changes and deploy those changes to the local website. The time it takes to download changes vary based on the amount of changes and the distance between web role and blob store - we have our store in an European data center and accessing this is visibly slower when done from an Asian web role

Scalability, data store and state

In our setup the public facing website has no state that needs to be shared across instances. The CMS data is stored using our default XML data provider and there is no dependency between the blob storage and running the web site (only for pushing updates). This makes web roles very autonomous and if you deploy on two or more web roles at each geographical location you have no single point of failure and there is no shared resource preventing this model from scaling.

If the need to share state across web roles should arise nothing in this deployment model should prevent us from building the required features and use services like the blob storage and SQL Azure to store files and data managed from the public facing sites.

What did it cost?

We are running 6 extra small web role instances on Windows Azure – this costs approximately $280 per month – all inclusive. The Geo DNS service is free and the Composite C1 Azure tools are around $50 per month.

This brings the total costs of this setup to $330 per month. There is no starter fee.