ASP.NET Performance Practices

In this article we will explore some tips for improving ASP.NET performance.

Before starting I would like to request the reader to put some ideas and tips for improving ASP.NET performance.

1. Practices for Data Tier

Database plays a very important role in performance improvement.

• Avoid multiple round trips to database.
• Always use stored procedures
• Avoid using dynamic queries and Cursors.
• Set NoCount ON, unless and until you require the number of rows affected.
• Avoid querying the same table multiple times in a single session/stored procedure.
• Choose properly between Table Variables and Temp Tables.
• Temp Tables are more preferred when the number of records is greater.
• Avoid putting too many indexes into a table.
• If a column is not going to repeat its values, then assign a unique key to it (assuming a primary key is already assigned to some other column).
• Union all is more preferred than Union.
• Avoid writing co-related sub queries like:
  
  Select * from TblEmployee where EmployeeId =(Select EmployeeId from TblAttendance where leaves>1 and EmployeeId= TblEmployee.EmployeeId).
  (Try to use a Join instead.)
  
• If you are sure about the number of rows to be returned by a query, set the Row Count to that number.
  
  Example : Let's say for instance it's 2, then:
  
  set RowCount 2
  Select * from TblEmployee where where1=@where1 and where2=@where2
  set RowCount 0

2. Paging

Whenever a list of data is needed to be shown, apply paging and show only some records in every page.

3. Layout

Prefer Div Layout over Table Layout. Tables save HTML development time but create performance overhead since the browser must often wait for the whole table to load before it can begin to layout the content.

4. Caching

Try to cache the things which are more on static or will not be changed frequently.

ASP.NET provides substantial support for caching by means of Page Caching and Fragment Caching.

5. Threading

Using threads in an application improves performance by a great extent.

Let's take an example where we can use Threading in ASP.NET.

Consider there is a form with many input fields to be dumped into the database on submit and after that mail must be sent to admin as a success receipt.

With the mail being sent by a separate thread, it is completely independent of the UI rendering.

Note: A thread can be counter-productive if used excessively; in other words, performance will be affected in a reverse manner when a Thread is used excessively.

6. ViewState

It's one of the biggest culprits for performance issues in ASP.NET.

Always disable the ViewState when it's not necessary, like in the case that we have a form filled only with textboxes, the ViewState is not required because, textboxes maintain their values from the postback data regardless of ViewState.
(Please go through the ASP.NET life cycle first.)

Complex controls like a GridView maintains a very large amount of ViewState, better disable it and rebind it when it's required.

7. SessionState

• Do not overuse Session State for user data storage.
• Choose proper session state (InProc, OutProc).
• Avoid storing complex objects into sessions because such things involve serialization and deserialization internally which results in a big performance penalty.
• If a session variable is no longer required then clear it.
  
  Note:
  
• ViewState is used to store Page-specific data whereas Session is used to store user-specific (in other words, stored in server memory).
• More things in ViewState means slow page, more things in session means slow website.
• The above statement doesn't mean we should go with ViewState always, it's up to the environment and condition.
  
  For example consider we have to store a huge amount of data but the website is not going to be accessed by many users; there might be one to three users that will access it simultaneously. In this case the session will be worthwhile.
  If you try ViewState for such huge objects pages then it can get extremely heavy and might not even load.

8. Set retail="true" in your machine.config

<configuration>

<system.web>

<deployment retail="true"/>

</system.web>

</configuration>

• It will force the "debug" flag in the web.config to be false.
• It will disable page output tracing.
• It will force the custom error page to be shown to remote users rather than the actual exception or error message.