Home » ASP.NET » Tracking Down Performance Issues in ASP.NET

Tracking Down Performance Issues in ASP.NET

Last night, one of my clients assigned me a problem that I thought was going to require one solution, and in the end it was just poor programming. But the process reminded me of the need for good debugging skills. Just how do you know where the performance problem is?

Too many programmers I know approach performance issues from the front end. “I know there is going to be a performance problem if I do it this way, so I’m going to do it that way instead.”

But unless your theory was correct, you are very likely to spend extra time doing something you may not need to do. While solving problems is what makes programming fun for a lot of us, solving problems that don’t exist is a waste of time for the organizations we work for.

My motto is:

  • Get the app working
  • Get the app working right
  • Get the app working fast

By following these steps, in this order, I very rarely even need to address step three.

So, what happens when there is a performance problem? How do you track it down?

Well, hopefully, you are addressing a visible performance problem. Something is taking more than a second to run. There are cases where you need to address performance problems that are less than a second and/or can’t really be measured with a stop watch. But the biggest hits are the easiest to solve. So all you need to do is set some break points in your app and count how long it takes to get from one to the other. This is where a good layered architecture helps a lot. Very rarely is the performance issue in the display code. So you can set a break point in the code that gets the data out of the database.

When I did this this morning, I found that there was a foreach loop in the BLL that was retrieving data that could just as easily be placed in the store procedure that we were calling right above the foreach loop.

That seemed to solve the problem until we put the code on stage. And, this is where the fun began. While the code was definitely faster, it was still too slow. What was perplexing was that the data seemed to be the same in our test database as it was on staging. Worse, we no longer had access to our debugger. So, how do you track a problem like this down?

This is where the tracing feature of .NET is of great value.

If you’ve never used this feature, you can read some other articles about it elsewhere (I’ll place links at the end) but for our purposes, we want to set up tracing a specific way.

  1. Place the following line in web.config
    <trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="false" />

    This will enable tracing for your application but will not display the tracing information at the bottom of the page. Set localOnly to true if you can access the information from localhost–otherwise, you’ll need to set it to false.

  2. Put tracing statements in your code that you are trying to get timing information for.

Now, here’s the part many people don’t know. While it is pretty simple to send trace statements out from the codebehind file using:


You can also access the Trace object and emit trace statements from your BLL and DAL code using:


To access the trace output, run http://domaainstuff/applicationdirectory/trace.axd and select the round trip you want to examine.

Other places talking about ASP.NET Tracing:

Tracing Tutorial
The Basics of ASP.NET Tracing
ASP.NET Tracing article at 4guysfromRolla.com

Other places talking about ASP.NET performance:

ASP.NET Performance Tips


Other post in ASP.NET

Related Post

  • HttpContext.Items[] vs Session[]HttpContext.Items[] vs Session[] Since .NET first became available, passing data around during a request has become a lot easier.  The ability to set a property has made that so.  Still, there are times when […]
  • ASP.NET Interview Questions For New College GraduatesASP.NET Interview Questions For New College Graduates I’m not the first to write on this topic and probably won’t be the last.  But I do have something to say on the matter that I think is helpful. In fact, there has been quite a bit […]
  • FormView Edit and AddFormView Edit and Add The FormView generally makes editing a record at a time pretty easy.  However, one of the biggest problems I've seen with this control is that there is no way of telling the FormView to […]
  • Response.Redirect() executes too soon on the Server.Response.Redirect() executes too soon on the Server. I've seen this question a couple of times in various situations. The first involves Javascript and the second involves server side code. Both are caused by a misunderstanding of what this […]
  • Dynamically Change class Attribute From ASP.NETDynamically Change class Attribute From ASP.NET I recently received a question from another programmer I know who's been using PHP prior to ASP.NET that made me think harder about a problem we've all had in ASP.NET.  The basic […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback