In its previous incarnation before the heady days of Xbox LIVE, AlphaJax was running on dedicated virtual servers. These served their purpose reasonably well, but what about when the time comes to scale out to an unknown large user base? Because of this, the decision was made to move the AlphaJax back end to Azure.
The game itself connects to .Net 4.0 WCF services tuned for JSON over REST. This was a perfect candidate for cloud services in Azure ensuring that we could assign multiple instances and cores to the task of processing web requests from the game. The Medium sized server is a nice base instance option in this respect, giving you 2 cores, 3.5GB of Ram with high I/O performance.
AlphaJax does cache a small amount of stuff in Application Cache, but it’s so minimal we haven’t yet had the need to make use of dedicated caching services from Azure, but these are an option if you need to offload a lot of caching and don’t want to burden your cloud service instances with this workload.
When configuring WCF for high load, it’s important to understand and apply the correct configuration, essentially you need to understand the best model for concurrency and instance context.
To mimic a single active thread per request you should configure your wcf service implementations as follows:
As well as talking through to a data layer, the AlphaJax service layer needs to communicate with 3rd party services such as the Microsoft Push Notification Services (MSPNS) to send out tile updates, chat messages and in game updates to your opponents when you play moves and so forth. You should make sure and override the maxconnection setting for sytem.net/connectionManagement in your web.config, so that your cloud services are not unnecessarily limited in the amount of connections they can make with external services.
Fortunately, WCF 4.0 has pretty sensible default settings, but you can enforce higher limits on the amount of concurrent calls and instances WCF can handle, using the serviceThrottling element as below, the actual values will depend on your requirements and application capabilities. Optimizing WCF Web Service Performance is an article describing this in detail.
On the back end AlphaJax makes use of a finely tuned SQL Backend to store all the game data. The transition to SQL Azure proved relatively painless and whilst SQL Azure databases are a little more expensive than Azure storage, they can provide low transition costs if you are coming from an already existing SQL back end. In future as usage grows, we expect to place more reliance on Azure storage for the ultimate scalability around matchmaking, core gameplay, and retain the SQL Azure part for reporting and rating aspects such as leaderboards and statistics.
Alphajax stores live tile images of games in blob storage so if you pin games to your start screen, the Cloud Services will store, cache and retrieve the images used to display on your screen. Azure Storage is a cheap and fast storage solution allowing you to store practically unlimited amounts of data in the most cost-efficient way.
The Windows Azure Portal - Easy Scaling and Monitoring
The latest incarnation of the Windows Azure Portal is a pleasure to use and has been provided with many usability enhancements since the early days. You can easily access Cloud Services in the left hand menu and this presents you with a Dashboard of your environment.
If you need to scale out or in, you can just click on the SCALE heading and adjust the slide to add or remove instances, it’s as simple as that. And you can also automate the scaling using Microsoft patterns and practices guidance or their are 3rd party auto-scaling services you can use like Paraleap’s AzureWatch.
If you need to view detailed information about CPU, Ram, Concurrent Connections, Total requests executing you can do this via the MONITOR heading. Note that you may need to go to CONFIGURE and enable Verbose logging on your cloud service to get all the additional metrics. I find this view provides a great deal of clarity around the performance of AlphaJax.
Deployments made easy - Smoke Test with Staging, then Swap in place to Live
For uploading new versions into production, you can make use of the “staging” environment which will give you a testing url in the production environment that you can test against, and then you can click the SWAP link and almost instantly swap out what was in production with the staging environment. Nice and simple and works really quickly as it’s just switching ip addresses around.
It’s a great way of doing smoke testing and also “warming up” your instances before putting them into a properly live environment. It’s to be noted that there is no downtime during this operation, it’s a pretty seamless transition and a painless way to do upgrades.
This post provides a flavour of the main parts of Azure touched on by the Windows Phone game Alphajax.
Overall, Azure has been a pleasure to use and I wouldn’t hesitate to recommend it as a solution to back mobile apps on any platform. It has services to suit any budget and can scale to meet the most demanding of requirements with offerings to help you out as you move along this spectrum.