March 15, 2010, 5:25 PM — If you or your company are setting up a new web site, you might want to know how that web site is going to stand up to heavy traffic. How will it respond, for example, if 50, 100, 200 or 500 visitors are using your site at the same time? Will response time for people on the other side of the country or the other side of the world be significantly longer than response time for people across the street? You can find out how your site will respond to heavy usage without waiting for it to happen.
Depending on your time frame and budget, you can hire a company like Keynote, WebMetrics or Xceptance to work up the details of your stress testing or work up your test scenario on your own with an inexpensive service like LoadImpact. What you will probably want is the ability to control when and how your tests are done, how many concurrent users you want to simulate and from where the web requests are generated. You could try using an application that runs on your desktop, but you're unlikely to be able to ramp up to the higher stress levels or discover how response times differ depending on the location of the requests.
For example, you might specify that your load tests will start by simulating ten concurrent users and then ramp up in groups of ten (10, 20, 30, etc.) until you have reached 100 or 200 concurrent sessions. You might request that the load demand derives from a mix of locations far and near or you might run two load tests -- one employing local systems and one using systems at a distance so that you can see the effect of location on response time.
The rule of thumb that I've been living by for many years now is that most web visitors will lose patience after about seven seconds of waiting for a page to appear. If your response time approaches seven seconds when your testing with only twenty concurrent simulated users, you probably ought to take another look at how you are generating your web pages. If it doesn't start timing out until you have several hundred simultaneous users, you're probably in good shape.
The numbers that work for you depend on the kind of site you are supporting. If you work for a company the size and web presence of Google, eBay, Amazon or E*Trade, several hundred simultaneous users is likely a drop in the bucket. Your site no doubt employs hundreds or thousands of systems, real or virtual. If you work for a medium sized company, on the other hand, testing with a hundred or so concurrent users is probably realistic.
Of course, it's a good idea to stress test a web site when it's not busy (so you don't affect real users) or, better yet, before you put a new site online (or when one server in a redundant set can be isolated for just this purpose). Don't forget that heavy load testing is going to affect your firewalls and routers too, so make sure you properly inform and involve everyone who might be alerted if a problem arises.
Most web load testing sites will allow you to prepare a script or record a series of page requests so that they can be played back repeatedly, thus representing typical web usage patterns. You may pay several thousand dollars for a test lasting a few hours or get by with a $49/day service (more or less), but it's a good idea to know how your web site is going to respond to traffic before launching it into service.
You can learn more about load testing at web sites such as these: WebMetrics , Keynote, Xceptance and Load Impact.
