Microsoft suggests the following to help get the most out of the test runs:

Best Practices for Performance Testing

Do

• Clear the application and database logs after each performance test run. Excessively large log files may artificially skew the performance results.
• Identify the correct server software and hardware to mirror your production environment.
• Use a single graphical user interface (GUI) client to capture end-user response time while a load is generated on the system. You may need to generate load by using different client computers, but to make sense of client-side data, such as response time or requests per second, you should consolidate data at a single client and generate results based on the average values.
• Include a buffer time between the incremental increases of users during a load test.
• Use different data parameters for each simulated user to create a more realistic load simulation.
• Monitor all computers involved in the test, including the client that generates the load. This is important because you should not overly stress the client.
• Prioritize your scenarios according to critical functionality and high-volume transactions.
• Use a zero think time if you need to fire concurrent requests. This can help you identify bottleneck issues.
• Stress test critical components of the system to assess their independent thresholds.

Do Not

• Do not allow the test system resources to cross resource threshold limits by a significant margin during load testing, because this distorts the data in your results.
• Do not run tests in live production environments that have other network traffic. Use an isolated test environment that is representative of the actual production environment.
• Do not try to break the system during a load test. The intent of the load test is not to break the system. The intent is to observe performance under expected usage conditions. You can stress test to determine the most likely modes of failure so they can be addressed or mitigated.
• Do not place too much stress on the client test computers.

Okay, the test run is complete. Now comes the interesting part: analyzing the results. ACT provides a collection of application performance statistics, and you can collect more from your database and Web servers. Has the app kept up? Where are the bottlenecks? Now it's troubleshooting time.

Finally — well, not really finally, this is an iterative process — make some changes and rerun the tests. Analyze, tweak and repeat as required until the app meets performance requirements.

Then turn it loose on the world.

Want to learn more? Check out Microsoft's Patterns and Practices group's document on testing .NET application performance.