Monitoring and Improving ASP.NET Application Performance
There are a plethora of performance counters installed with the .NET framework and ASP.NET. There are counters to keep track of errors, requests, cache ratios, transactions and more.
In this article, originally published on ASPToday, James Avery is going to look at using these counters and the Windows Performance Monitor to monitor the performance of your ASP.NET applications.
www.ASPToday.com is a website resource established since the early days of ASP. This unique solutions library for professional ASP and ASP.NET developers has a growing archive of well over 1,000 fully searchable solutions, tutorials and in-depth case studies. We publish professionally written and reviewed content every day ~ consequently our resource is completely without parallel in the industry. Thousands of web developers use and recommend this site for real solutions, keeping up to date with new technologies, or simply increasing their knowledge. There is always free content available on ASPToday, but subscriptions range from $10-per-month to $99 for a full 12 months' access to all areas of the site.
This article was originally published on www.ASPToday.com.
By monitoring the performance of our applications we can prevent performance issues before they ever arise, and we can further optimize our applications to provide an even better user experience. We can also use the Performance Monitor to help us in determining how much hardware we will need to sustain our application.
In this article we are going to take a look at how we can use the Performance Monitor and the performance counters that are installed with the .NET framework to monitor and improve the performance of our ASP.NET applications. We are going to talk about what counters are the most useful to us, what tools we should be using, and how to create an application monitoring plan.
A very important part of monitoring the performance of our applications is planning. The first thing we need to do before we start any tests is decide what counters we want to track, when we want to do the testing, and how often we will do the testing. We do not want to start making changes to our application without being absolutely sure that we are using accurate performance data. To get the most accurate sampling of data we want to be sure to monitor our applications at different times of the day, or for very long periods of time. You also have to take into consideration when an application will be used the most, during a certain time of the day, or a certain day of the week. The first thing that we need to decide is the timeframe that we will be using to monitor our application. In our case we will be using 15-minute intervals for the sake of convenience, but when monitoring live applications I like to monitor it for a 24-hour period on a 10-second interval, as it will give us an accurate view of the performance for the entire day.
The second thing we need to decide on is what we will be monitoring. For our examples here we will be monitoring three different things, the cache performance, request performance, and error performance. When we setup our performance monitor we will include counters for cache, requests, and errors, but when viewing the results we will view them one at a time. When deciding what aspects to monitor sometimes it is best to simply include all of the ASP.NET performance counters and then view them one at a time in the performance monitor. When you see which areas you are having problems with, you can then just monitor those areas on subsequent tests.
The last thing we need to consider when creating our performance plan is how many times we will test, we do not want to make major changes to our applications without at least running a couple tests to be sure the results were not a fluke. Let's take a look at the performance plan for the test we are going to perform here:
Time: (duration of our test)
Counters: (which counters we will we be monitoring)
Cache Hit Ratio
Cache Turnover Rate
Tests: (the number of tests we will run)
When: (when we will we run the tests)
Test 1 will be run on a weekend day
For this example we are only going to be running a single test, as it makes it easier to understand, but in a real life testing scenario it is a good idea to run multiple tests at different times or on different days. This helps to ensure that the results confirm that there is indeed a problem before making any changes. I have decided not to include a test application because I want everyone who wants to follow along to perform these tests on their own live applications, just like I will be doing here. Using test applications can be very useful, but nothing beats actually monitoring the performance of your live applications. I have included the performance log files if you want to view the same data that I am viewing here.