Your new ASP .NET networked app is so ready. It has been code checked and tested and fixed and retested until it positively glows with readiness. The test users are purring in delight. The Big Boss has signed off.

Time for the rollout.

Or is it?

The app works with ten users, but how will it cope with 100, or 1000, or 10,000? If it's Web-based, how about a round million? All at once.

Maybe there's one more teeny step that would be useful before you foist this gem on the world: load testing.

Pshaw, you say, it'll be fine. The architecture is solid.

Uh-huh. That's what they probably said at Carl Jr.'s when they mounted their sexy Paris Hilton ad on the Web, before the site collapsed under the strain. Or at Continental Airlines, whose seat sale brought their site to its knees for ten hours. Or at British retailer Marks and Spencer's, whose one-day "20 percent off on Web purchases" promotion made their site go toes-up for hours.

You can never tell.

Inside a company's walls, it's easier, because you have a finite number of possible users, but it's amazing how the user base can grow. A simple application running on an Access database over the Intranet — say, a department's time tracking program — could catch the eye of managers in other departments, and before you know it, that little app has spread like a virus throughout the company. How much can it take? Who knows, until it faints, hopefully without corrupting the database.

Load testing, and its companions, stress testing and capacity testing, will answer many of these questions. It shows you how an application (and the system it runs on) performs under various loads, how it copes with heavier than usual traffic, and at what point it will break entirely.

No, you don't need to find a million testers to try this out. There are plenty of tools that simulate various loads and log and report system reaction to them. One of them even comes with Visual Studio .NET Enterprise Edition: Microsoft Application Center Test (ACT). A second one, Microsoft Web Application Stress Tool, can be downloaded.

First thing's first, though. Before you start messing around with the tools, you need some objectives to test for, such as, say, a service level agreement you have to fulfill. This may include metrics for latency, throughput (number of requests serviced by the app per unit of time), resource utilization (disk, CPU, I/O, whatever is appropriate), and workload (number of concurrent users).

Once you've nailed those down, it's time to design scenarios to test with. For example, on an e-commerce site, a visitor will browse product offerings, put items into a shopping cart, and check out using a credit card. You have to define the breakdown for each activity (for example, in a given period 20% of visitors are putting items into shopping carts and 50% are browsing the catalog), so you can measure resource requirements and ultimately optimize to eliminate bottlenecks.

Then you build the test loads; if you're using ACT, create an ACT project. You can either write a script from scratch, or use recording mode as you browse and shop and tweak the mix of activities later. Remember to add "think time" — delays that would naturally occur as the user reads a page, or fills out a form, or meditates on which item to purchase (of course, if you really want to slam the server, you can omit the think time and send a steady stream of commands). You'll find basic instructions here.

Decide how long the test should run, and how many users it should simulate, and fire it up. (You are working with test systems that approximate the production systems, not the production systems themselves, aren't you?).