Thursday 25 March 2010

Azure to the rescue

Developers following the build of the new Tesco Grocery API, (an R&D project that allows third-party access to our grocery service through their own applications) may well have questioned a consequence of enormous download counts for our iPhone Clubcard app.

The question: If we had similar downloads for the forthcoming Tesco iPhone Grocery app, how will the API cope if it is still in R&D?

The blunt answer is that it won't. My tests have shown that currently the API service can survive processing around 400 simultaneous HTTP requests on its server - any more and performance begins to suffer - not very useful if several thousand customers all start trying to synchronise their favourite products (a key feature of the grocery app) at the same moment in time.

What to do? Productionise the API, of course! Well that work has already started but it's going to take a while to complete, and we want to launch sooner rather than later.

The good news is the API has been created as an ASP.Net application - perfect for being hosted within the new production Windows Azure cloud computing platform. An early version was running in an equally early version of Azure during 2009, so the design takes account of operation within the cloud. It's also been upgraded recently to work in .Net Framework v4.0 and ongoing developments use the Visual Studio 2010 dev environment, so it's 95% cloud-ready right now.

Importantly, the API does not itself store any personal information since it acts as a proxy between client applications and the new 'Project Martini' grocery service running on the live Tesco.com web servers. That's important as it would be difficult to describe where the Azure SQL databases actually reside to the Data Protection Registrar, so thank goodness it doesn't need any such registration.

Tomorrow it's a case of adjusting the API source code to work fully within Azure's development fabric, then upload it to the Azure cloud for some stiff weekend performance testing. Indeed I need to turn up the stress on the API until it starts suffering in terms of performance, then I'll be able to calculate how many CPUs and other Azure resources are needed to scale the service upwards to cope with possibly thousands of simultaneous users.

Cloud computing is a great way of 'taking the strain' with services - particularly with peaks that will no doubt be experienced after an app launch - I'll let you know how the Azure-hosted Grocery API behaves over the coming days - and post launch.





3 comments:

  1. Hi Nick,
    How are you going to be doing the load testing? I've always thought that Azure itself would be a great method of simulating many users simultaneously hitting the service.
    "Oh, you want 1000 users on demand for a sustained 5 minute period?" Well, that'll be 1000 Azure compute instances. Done. Next?"

    -Jamie

    ReplyDelete
  2. Hi Jamie

    Yes that's exactly how I'm going to do it!

    I suspect that a single Azure computer instance can process more than one request at the same time, so I need to turn up the load on a single compute instance by sending it more and more simultaneous requests until performance falls below a certain threshold (whatever that is - say, 20% increase in response time compared to a single request), then multiply up accordingly.

    I'll document here as I go to see what happens.

    ReplyDelete
  3. Good stuff, I look forward to hearing about it. There's been precious little case studies about testing peak load scenarios and that really surprises me.

    -Jamie

    ReplyDelete

As this blog grows in readership - and because it carries the Tesco brand - I have had to become more careful about the sort of comments that are acceptable. The good news is that I'm a champion of free speech so please be as praising or as critical as you wish! The only comments I DON'T allow through are:

1. Comments which criticise an individual other than myself, or are critical of an organisation other than Tesco. This is simply because they cannot defend themselves so is unfair and possibly libellous. Comments about some aspect of Tesco being better/worse than another equivalent organisation are allowed as long as you start by saying "in my personal opinion.." or "I think that...". ... followed by a "...because.." and some reasoned argument.

2. Comments which are totally unrelated to the context of the original article. If I have written about a mobile app and you start complaining about the price of potatoes then your comment isn't going stay for long!

3. Advertising / web links / spam.

4. Insulting / obscene messages.


Ok, rules done - now it's your go: