Blog Post by Murat Yaşar

1. Blog
2. Tuning, Optimizing, Increasing and Improving Performance of Asp.Net Application - Part I
3. Technical

---

Posted on Saturday, January 23, 2010 1:26:16 PM and it has been read 6369 times since then.

---

Tuning, Optimizing, Increasing and Improving Performance of Asp.Net Application - Part I

You can reach other two blog entries which are also part of this series from the following links:
In this entry, I will be focusing on the code behind and markup files...
In this entry, I will be focusing on the MS SQL Server and T-SQL...

There are many things we should do for being able to say that my application is working when we are about to go public. Every day we experience different bottlenecks and taking the necessary steps to prevent these to happen in the future.

However, things we should do never ends and they will never be. Some problems might occur because of our code or the environment we are executing our app in. Probability of problems and its source varies and not easy to find in one go, even though we anticipate every possible setback and taking again the necessary steps. Let us say from error handling to getting notified when something goes wrong. Kind of digging a tunnel with a needle.

As you all know, performance tuning one of the considerations we need to be aware of. We can write code, publish it and sit back but how long for!  Well it depends on the way we design our application and how tightly we apply experts advice, best practices and recommendations. Either from the beginning or some time after we can start experiencing troubles, complaining from users and all sorts of undesired happening, even though we tightly applied all the rules, best practices. The reason of complainings might not have been there before but came to light after some hardware or network failure or inefficient working. In this 3 part of series I will not talk about any of these problems but just try to shed light on tuning and performance things. May be a little bit best practices but I do not claim at all that I write the best practices. Kind of check list before going to public with our app.

You can find many links which talk about best practices, performance tuning, writing efficient code in both .Net and SQL environment, steps that we should always take while writing code, designing our database. What I tried to do here is that I gathered a big check list which embraces many keep in mind things at first for myself and later thought would be also beneficial for the community. I visited many websites, read articles, things we should keep in mind, best practices but they are all in different sources. I wanted to see them in one place and kind of check list manner for myself before publishing whatever application I am about to publish and in my case it was an Asp.Net application which talks to heavily with MS SQL Server. I also gathered many links, thought they are good and must or should be read ones. I am sure there are plenty of links available which talk about the same thing I talk here but just did not find them. You can add those links as a comment to benefit others and me from it.

Again, I read and created kind of check list for myself at first and thought would be beneficial for others if I publish this gathering as blog entries. So, I hope you can get some extra keep in mind things which you have not known or heard it about before.

In the first part of this three-part series, I will try to give you some of the precautions that we had better pay attention in web.config file before going public with our asp.net application. These are my collection from the internet. I just wanted to give you a check list which consists of as many item as possibly could be in it.

Since I told you that I gathered many links from the internet, I wanted to specify some of them in here. These are the links which -I think- are helpful while optimizing and tuning your Asp.Net application as well as your T-SQL code.

http://msdn.microsoft.com/en-us/library/5dws599a.aspx

http://msdn.microsoft.com/en-us/library/ms998596.aspx

http://msdn.microsoft.com/en-us/library/ms998530.aspx

http://msdn.microsoft.com/en-us/library/ms998549.aspx

http://msdn.microsoft.com/en-us/library/ms971481.aspx

http://code.google.com/speed/page-speed/

http://developer.yahoo.com/performance/rules.html

http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx

http://articles.sitepoint.com/article/aspnet-performance-tips

http://dotnetslackers.com/articles/aspnet/SevenWaysToDoPerformanceOptimizationOfAnASPNET35Web20Portal.aspx

http://visualstudiomagazine.com/Articles/2005/11/01/Optimize-ASPNET-Performance.aspx

http://stackoverflow.com/questions/291415/net-performance-tips-for-enterprise-web-appilcations

http://robertnyman.com/2008/05/09/improve-your-web-site-performance-tips-tricks-to-get-a-good-yslow-rating/

http://www.codinghorror.com/blog/archives/000807.html

http://www.developerdotstar.com/community/node/531

http://vyaskn.tripod.com/coding_conventions.htm

http://www.mssqlcity.com/Tips/tipTSQL.htm

http://www.dotnetfunda.com/articles/article45.aspx

http://balavardhanreddy.over-blog.com/article-34787540.html

http://sqlblog.com/blogs/aaron_bertrand/archive/2008/10/30/my-stored-procedure-best-practices-checklist.aspx

Part I : Web.Config

1-) We should set the value of debug to false inside compilation tag in web.config file.

<compilation debug="false"/>

If we set this to true, number of unwanted things happen on production which kills the application performance. You do not need it set to true in production and it often leads to memory overhead and inefficiencies. As Scott Guthrie talks about it in his blog the following lines are the some important negative impacts.

- The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled).

- Code can execute slower (since some additional debug paths are enabled).

- Much more memory is used within the application at runtime.

- Scripts and images downloaded from the WebResources.axd handler are not cached.

---

2-) To optimize the ASP.NET AJAX in our web application, we need to make sure the Compression and Caching is enabled in web.config file. Even though we enabled it, it can not work the way we want it to work in IE6. Due to some bug in IE6, you might not get the benefit.

The following link talks about this issue in IE6.
http://forums.asp.net/t/1145443.aspx

<system.web.extensions>    
   <scripting>    
      <scriptResourceHandler enableCompression="true" enableCaching="true" />
   </scripting>
</system.web.extensions>

Take a look at these links to get more information:
http://lancezhang.wordpress.com/2008/11/15/aspnet-ajax-performance/
http://weblogs.asp.net/scottgu/archive/2005/06/28/416185.aspx

---

3-) Set mode to RemoteOnly for customErrors tag if you specify any.
Well this is not necessarily very important from performance stand point but I thought that it would be appropriate talking a little about this as well. Scott Guthrie gives a good explanation on this subject.

Take a look at these links to get more information:
http://weblogs.asp.net/scottgu/Tip_2F00_Trick_3A00_-Show-Detailed-Error-Messages-to-Developers

---

4-) Turn off Tracing unless it is required.
Tracing is awesome, however have you remembered to turn it off? If not, make sure you edit your web.config and turn it off! It will add a lot of overhead to your application that is not needed in a production environment.

<trace enabled="false" pageOutput="false" traceMode="SortByTime" localOnly="true" />

Take a look at these links to get more information:
http://blog.brianhartsock.com/2009/02/24/importance-of-trace-enabledfalse/

---

5-) Turn off session state in web.config file or at least for a page if there is no sessions.

If you're not using Session State at all, turn it off completely via web.config file:

<sessionState mode="Off"></sessionState>

If you're using Session State, but it's required only for a few pages, then first turn it off for all pages:

<pages enableSessionState="false">

Then enable it for a specific page:

<%@ Page ... EnableSessionState="true" %>

---

6-) Select the Release mode before making the final build for your application. By default it is in Debug mode.

Make sure you use Release Build mode and not Debug Build when you deploy your site to production. If you think this doesn't matter, think again. By running in debug mode, you are creating PDB's and cranking up the timeout. Deploy Release mode and you will see the speed improvements.
http://blogs.msdn.com/tess/archive/2006/04/13/575364.aspx

---

I will be updating this entry if there is any new option to consider as well as a new link which explains better the option we are talking on.

Have a great day.

---

---