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.
Hi Nick,
ReplyDeleteHow 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
Hi Jamie
ReplyDeleteYes 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.
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.
ReplyDelete-Jamie