Recently, I did some work at a customer who was having performance problems in their SharePoint environment and their custom web parts. A target web page test should perform such that the average page time is less than 3 seconds—even under a heavy load. The average page time was good when only a few users were utilizing the application; however, when the user load and the number of requests / second increased, the page time was exceeding 3 seconds (it was actually around 10 seconds). Besides determining the problem, they wanted to find which was the culprit—the infrastructure and/or the code.

Visual Studio 2005 Team Suite to the rescue!

I determined this was a great scenario to use the new Test Suite built into the Visual Studio Test suite. I began by installing the Visual Studio Load Test Agent on 3 machines so I could perform a larger scale test—the agent allowed me to test the number of concurrent “users” making requests and I could test from different subnets to diversify the connections. Then, I created web tests for specific pages (only 1 page per test so I could get readings of the performance counters for an individual page). The specific counters I paid attention to were:

• Average requests / second
• Average response time (for the page alone as well as subsequent requests for CSS, images, and scripts)
• Page response time – which is the average time it takes the browser to download all the data the page is going to display (including CSS, images, and scripts)
• User load – the number of concurrent threads making page requests

Test Strategy

Note: I do not advocate doing stress testing in a production environment. If you do plan on doing so, you should notify users of the site outage. Load testing pushes a server environment to its limits to determine places where the infrastructure could fracture and where the application becomes unusable because the environment is overloaded.

1. Finding infrastructure problems:
   1. Perform multiple tests of the application in the troubled environment before making any changes. This is to set a baseline for the environment.
   2. Since we were trying to find infrastructure problems, it was necessary to modify the environment and perform multiple short tests (2 minutes) to gather metrics.
2. Finding code problems:
   1. Copy the code into a Virtual PC environment and stress test it to get some baselines.
   2. Add/remove web parts to determine if the problem lies in the:
      1. Number of web parts
      2. A specific web part type
      3. Web service performance
   3. Stress test the code after significant code changes to gather the metrics.

In the end, this strategy worked out rather well. I was able to gather metrics to demonstrate which changes in the environment and changes in the code showed improvment to optimize the portal performance. After using the Visual Studio Test Suite for a few weeks, (IMHO) I really think we (Microsoft) have a very high quality load testing software that will compete with other test tools, and because it is built into the Visual Studio environment, it will be easy for clients to notice the tools are familiar and one doesn't need retrained for a different set of tools.

I advocate that everyone test his/her applications using these new test tools, especially since the .NET test tools are available in the Team Software Developer version of Visual Studio. The load test and web test tools are in the Team Test version. Of course, all the tools are available in the Team Suite version (exlcuding the Test Load Agent which is a separate product).

Cheers!