Guidelines to Creating a Good ASP.NET Application

The following are the some of the guidelines to create a good ASP.NET application.

• Disable session when not using it. This can be done at the application level in the "machine.config" file or at a page level.
• The in-proc model of session management is the fastest of the three options. SQL Server option has the highest performance hit.
• Minimize the amount and complexity of data stored in a session state. The larger and more complex the data is, the cost of serializing/deserializing of the data is higher (for SQL Server and State server options).
• Use Server.Transfer for redirecting between pages in the same application. This will avoid unnecessary client-side redirection.
• Choose the best suited session-state provider - In-process is the fastest option.
  Avoid unnecessary round-trips to the server - Code like validating user input can be handled at the client side itself.
• Use Page.IsPostback to avoid unnecessary processing on a round trip.
• Use server controls in appropriate circumstances. Even though are they are very easy to implement, they are expensive because they are server resources. Sometimes, it is easier to use simple rendering or data-binding.
• Save server control view state only when necessary.
• Buffering is on by default. Turning it off will slow down the performance. Don't code for string buffering - Response.Write will automatically buffer any responses without the need for the user to do it. Use multiple Response.Writes rather than create strings via concatenation, especially if concatenating long strings.
• Don't rely on exceptions in the code. Exceptions reduce performance. Do not catch the exception itself before handling the condition.

// Consider changing this...try { result = 100 / num;}catch (Exception e) { result = 0;}
// to this...if (num != 0) result = 100 / num;else result = 0;

• Use early binding in VB.NET and Jscript code. Enable Option Strict in the page directive to ensure that the type-safe programming is maintained.
• Port call-intensive COM components to managed code. While doing Interop try avoiding lot of calls. The cost of marshalling the data ranges from relatively cheap (i.e. int, bool) to more expensive (i.e. strings). Strings, a common type of data exchanged for web applications, can be expensive because all strings in the CLR are in Unicode, but COM or native methods may require other types of encoding (i.e. ASCII).
• Release the COM objects or native resources as soon as the usage is over. This will allow other requests to utilize them, as well as reducing performance issues, such as having the GC release them at a later point.
• Use SQL server stored procedures for data access.
• Use the SQLDataReader class for a fast forward-only data cursor.
• Datagrid is a quick way of displaying data, but it slows down the application. The other alternative, which is faster, is rendering the data for simple cases. But this difficult to maintain. A middle of the road solution could be a repeater control, which is light, efficient, customizable and programmable.
• Cache data and page output whenever possible.
• Disable debug mode before deploying the application.
• For applications that rely extensively one external resource, consider enabling web gardening on multiprocessor computers. The ASP.NET process model helps enable scalability by distributing work to several processes, one on each CPU. If the application is using a slow database server or calls COM objects that access external resources, web gardening could be a solution.
• Enumerating into collections sometimes is more expensive than index access in a loop. This is because the CLR can sometimes optimize array indexes and bounds checks away in loops, but can't detect them in for each type of code.
• JScript .NET allows methods within methods - to implement these in the CLR required a more expensive mechanism which can be much slower, so avoid them by moving inner methods to be just regular methods of the page.
• Do a "pre-batch" compilation. To achieve this, request a page from the site.