What key performance monitors should I watch for ASP.NET application

Question

I have a site that receives 5 million request per day. On heavy days, the pages take about 10 seconds to return. I also get out of memory exceptions. I've been reading the Improving .NET Application Performance and Scalability from Microsoft and see there are a lot of metrics I could watch. My question is:

What are the most basic counters I should be watching that will :

• Tell me where the 10 seconds is spent
• Tell me where the memory is being used?

this is an ASP.NET 2.0 app running on Win2003 with IIS6

Answer 1

If you look at it from a very basic level you only have 4 main things:

• Disk
• CPU
• Memory
• Network

You can monitor these: Disk is queue length, the others are % utilization.

However, the problem may not be one of these. It could be a configuration setting that, for example, sets the max number of connections. A good place to start to look for these is the IIS error log or the Event log.

Answer 2

The key to an easy performance improvement isn't always the way your application is written. It could be written as perfectly as possible and still have performance issues. One way to get quick page loading times is to use page caching.

The following article is a good start.

Answer 3

Since the number of requests per day is about 5 million records, and growing,

I would suggest the following:

Client Side

Get Fiddler and get the readings of the number of requests per page and their turn around time. Do this for, first request and Consecutive requests. You should ideally sample the data for 5 first requests and 5 consecutive requests before sampling the data and drawing conclusions from it.

The parameters to read from it are:

• How many requests per page are happening ?
• How many of them can be cached ?
• The bottleneck resources ?

Server Side

To identify server side turn aroud time, I would suggest Ayendes, Rhino.HttpModule or someting, i don't remember exactly. It gives the turnaround time of a page at the server side.

The parameters to read from it are:

• Is it a server side Issue or a Client Side Issue ?

After this, you should be in a clear position as to whether it is a client side issue or a server side issue. Having doen that, then you can concentrate on the parameters.

On last note, I think you can do away with any changes to your code. Because, you are suggesting that under load, the turnaround time is around 10 seconds. See, the browser cannot request more than 6(+/- 2) resources at a time. So, something under load is loading your web server. Simulate the situation and see the request count, Team Foundation System, should help. Also, IIS reports , might provide the requests on the server side. Have a look at them. They might give you a clear picture.

Hope this would help.

Answer 4

You don't give any indications as to where the potential problem is, so start with the basics mentioned by @Shiraz. There are performance counters you can dig into that should give you an indication as to where the problem is.

Once you've narrowed it down to a particular area, you can then dig in a bit deeper to see if it's a coding issue, or a hardware issue.

But there's not going to be a magic "watch this" to solve your problem. Solving scalability problems is hard.

Answer 5

On the KPI:

Some already mentioned it in the other answers. I don't remember the actual counter names but in general: Requests Per Second (Web) % Processor (Web & SQL) Memory GC (large heap, Generation 0, 1, 2) Cache Hit Ratio for your SQL Server Disk Queue Length (Web & more importantly your SQL) any counter related to blocking and deadlock in SQL

On getting answer to your questions above:

Going through performance monitor won't really tell you the answer to your question. You might want to some web load testing since I guarantee your application will behave differently under load if you don't test for it.

Tools you want to try get familiar with to answer those questions are: .NET Profiler (to profile your ASP.NET code) .NET CLR Profiler (to profile the memory usage)

But still, create web tests first (you can easily do this w/ Fiddler for a start) and customized it further (to be able to do data binding) w/ VS and run load test w/ close to real data representation (in capacity) and number of users. From the web tests you should be able to tell which page are underperforming. Then drill down deeper with the profilers to find out why.

You are already in the right track looking at ScaleNet.pdf (or the online version). It's a bit dated, but it's still valid. Keep reading and applying things you read in there.