ASP.NET Performance Part 2 - Some testing Strategy

As you may be aware, I am very involved in performance testing as of late with an application me and my team have been working on for some time. In a previous post, I mentioned an isolated form of performance testing or profiling, using the freely available CLR Profiler.

Another part of my testing toolset is Microsoft Application Centre Test or ACT. It comes with Visual Studio.NET 2003 Enterprise edition and allows you to simulate a browser accessing your web application under various loads. It has its fair share of critics in that its not the most full featured performance testing tool around, particularly when compared to some of the commercial offerings, but it still can provide you with a good degree of load simulation and statistics for your web application.

I am not going to go into an explanation of a majority of the features, statistics and reports available in this post (thats reserved for perhaps my next post), I do want to mention an extremely valuable test strategy that has worked very well for me in this situation.

Our app communicates with approximately 6 other systems, mostly via web services. Obviously there is a degree of latency involved that would effect the overall throughout of the application. In order to determine whether just the application can handle specific loads, we built a series of configurable switches into the app early on in its development, that allows us the "stub" the various external system calls, with local response data. This means we can turn of all external system calls, run the application at high loads, and determine how much of our application can handle in an ideal situation. Then we can selectively, enable the external systems under various loads and examine the effect this has on the performance. From this we can deduce whether problems (in terms of performance) lie within our application, the external systems or our handling of the communication with those systems.

We have found this ability absolutely invaluable in proving our applications ability and allowing us to easily isolate problem areas at many different levels. When your web applications become a series of complex interactions between a variety of systems, these simple configuration switches have been well worth their implementation effort.

In my next posts, I will be dealing with client side statistics generated from Microsoft ACT, as well as server counters used for statistic gathering an analysis from Windows performance monitor.

1 Comment

  • ACT is good for high level profiling and gathering statistics. Using ACT we create baselines of memory consumptions, response times, total requests and so on with the system. Through real profiling we identify and solve potential bottlenecks. At this point we re-run the ACT test and compare the results fro the baseline...present the findings to our boss and make him happy.

    It's a poor choice for load testing and I'd say it's results can be more harmful than helpful if used as such in that they can be misleading...


Comments have been disabled for this content.