There is always that hope that marketing will strike gold and do something that directs massive new traffic to your website and assorted services. When that happens, will your website be able to handle it? In an article for The Server Side, Jason Tee discusses what to do to ensure your site is robust enough to handle your legions of new fans.
Bigger and Better
When new customers are drawn to a website by clever advertising or a major marketing campaign, and they discover that the website has gone down or is unusable from glitches, most of those people probably are not going to come back. Attention spans are limited, and windows of opportunity are called windows for a reason. In order to avoid losing customers, you need to think about scalability, but that means more than just provisioning for it:
Purchasing memory space or processing power for rapid scalability in the cloud is not enough. These additional resources will do you no good at all if your applications are not designed to actually function when they are hit with high demand. Doing load testing early and often in the development of a business application is the best way to ensure that it will be scalable. The next best thing is to uncover scalability issues through rigorous testing after the application is already built and deployed. The worst outcome is to find out that your application does not scale well when it’s actually put to the test in a real world situation. By that time, it’s too late.
What you can do, among other things, is take advantage of test environments in the cloud temporarily to get the information you need. Tee lists various metrics you should be on the hunt for at given stages, like how many pages customers visit and how long they spend on them, most visited pages, how a new customer tends to navigate a page versus a seasoned one, and how long and dense peak activity periods tend to be. This information will at least apply to your load testing.
For true scalability testing though, you will want to weed out where in your infrastructure that bottlenecks might occur. Places to inspect include web/application/database servers, drivers, actual application code, and the firewall. Obviously, testing these things when there are so many diverse variables at play is not as easy as one article might make it sound, but a little vigilance never hurt anyone.
You can read the full article here: http://www.theserverside.com/feature/Discovering-the-right-metrics-for-scalability-testing