This post originated from an RSS feed registered with .NET Buzz by Pau Laudeman. Original Post: Stress testing SharePoint Portal Server 2003 tips Feed Title: Paul Laudeman Feed URL: /error.htm?aspxerrorpath=/blogs/paul.laudeman/rss.aspx Feed Description: Helping You to Make "Smart Clients" Smarter! Latest .NET Buzz Posts Latest .NET Buzz Posts by Pau Laudeman Latest Posts From Paul Laudeman

James Edelen has a great post on the steps to take in order to stress test a SharePoint Portal Server 2003 web site. We recently wrapped up development for our internal SharePoint Portal server project and performed much the same steps as did James, but we added some additional performance counters to our Microsoft ACT scripts. The benefit to adding performance counters in addition to just running tests against your site is that you can see how the server is performing under stress.

If you notice that any of your counters are abnormally high under your target loads, you can take steps to identify what the cause of the extra load is, and hopefully, tweak your configuration or code to bring the counters back down to acceptable levels while boosting your overall requests per second throughput. Microsoft has published several whitepapers (see the Microsoft Solution Accelerator for Intranets) that will help you identify which counters to use, what numbers to look for when testing (both in terms of overall request per second serviced by your application and counter numbers from your system), and how to scale up and/or scale out your SharePoint server farm to meet the demands of your users.

To add performance counters to your Microsoft ACT stress tests, right-click your defind test script, select Properties, click the Counters tab, define your collection interval (the default 10 seconds is good), and then add the performance counters you are interested in monitoring. After your tests complete, Microsoft ACT will add the performance counters you monitored along with the other information collected in reports.

Microsoft recommends that you monitor at least the following counters when stress testing SharePoint:

• ASP.NET Apps: Requests/Sec (for your SharePoint site)
• Logical Disk: % idle time
• Logical Disk: Avg. Disk Queue Length
• Memory: Available MBytes
• Network Interface: Bytes Total/sec
• Paging File: % Usage
• Paging File: % Usage
• Processor: % Processor Time
• System: Context Switches/sec
• System: Processor Queue Length

TIP: To visually compare different tests runs to each other, just check the checkboxes in the report list for the test runs you are interested in comparing. Retaining test results for multiple runs over time allows you to analyze and compare server performance as your server grows or under conditions that might seem to indicate a problem with the performance of your server.

Final Thoughts

• Define your performance goals at the same time you are defining the requirements for your application.
• Get a good sense of the number of users who will be accessing your application, what their expectations are in terms of page performance and responsiveness, and how they will be accessing your site (broadband, vpn, dialup, etc.). Plan for future growth that is aligned with the growth of your business.
• Test your site throughout the development cycle to ensure that you are at least meeting and hopefully(!) exceeding your original goals.
• Create tests that simulate real user behavior on your portal site. Define the common paths and actions that users will take and script your tests around those behaviors.

Additional Resources

• Microsoft's Improving .NET Application Performance and Scalability guide (see Chapter 16 and Chapter 17 in particular)
• Performance Monitor: How to create a log - shows you how to capture counter information at scheduled times for later review (TIP: you can also create alerts that will notify system administrators when counters exceed a pre-defined threshold)
• Performance Tuning Guidelines for Windows Server 2003