Performance Load Testing

Before you even think about load testing your web application you should have a target/goal for what it is you want to achieve in terms of concurrent users and the response time for the resources (e.g. web pages) those users will be accessing. Without this, even if you are able to measure something about your system, you won't know how to evaluate your results. In order to have a pass/fail for your performance test, you need to have a goal to measure against.

Calculating The Goal

This article has a good explanation of how to go about calculating concurrent peak users and concurrent usage. In a nutshell you must start with some assumption around how many users will access the web application for a given time period. For internal/intranet application this might be all your employees that would make use of a time reporting application. For public web sites this is more difficult, but your application sponser/customer should have some idea of who their target user base is.

Number of Users

Start with your expected number of users per unit time. For example 1000 users/day. Then bound this with the window of time that the users will likely use the application. For most applications you cannot assume that their application usage will be spread across a full 24 hour window. For a internal business application it will be likely be something like 8 or 10 hours depending upon your company schedule. For public web applications it might be something longer like 12 or 14 hours - perhaps more depending upon how your users are spread geograhpically, especially if they are spread across time zones. Take these into account. Below is an example.

Users per day = 1000 User / day

You may need to include a fudge factor here like the article does.

Next limit this value to your expected time window and convert this to smaller time units such a minutes or seconds so that the value make sense in terms of session and or transaction times (which are likely not represented in smaller units of time).

Users per minute = 1000 User / day * 1 day / 10 hours * 1 hour / 60 minutes = 2 (rounded up to a while number)

Remember to make any adjustments based on how you think usage is spread across time - here we assume an even distribution of usage across time - this may not be a good assumption. For example if this were a time reporting/tracking applciation the window is likely made up of smaller windows of time (1 hour ) at the beginning and the end of the day. You must take these sort of impacts into account in the calculations.

Concurrent Transactions

Misc Links

I'm trying to work some of the content from these links into this page/article

• http://msdn.microsoft.com/msdnmag/issues/05/06/ExtremeASPNET/

• http://www.webperformanceinc.com/library/reports/TestingAspDotNet/

• http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en

• http://msdn2.microsoft.com/en-us/library/ms972959.aspx

• http://aspnet.4guysfromrolla.com/articles/062304-1.aspx

• Improving .NET Application Performance and Scalability

• 100% cpu

• How to streass test web applications

• Web Load/Stress/Stability and Performance Test Tools

Performance Counters

• Performance Counters Publishing Performance Data From Your .NET Applications by Lars Powers is an article from Code Magazine in March/April 2004 which explains the basics of windows performance counters including how to create your own custom counters.

• ASP.NET Performance Monitoring, and When to Alert Administrators by Thomas Marquardt on MSDN - describes what performance counters should be measured for ASP.NET performance monitoring.

• Chapter 15 — Measuring .NET Application Performance from Microsoft's patterns&practices

• How to fix errors related to registry access by the ASP.NET account

---

CategoryAspDotNet20