• 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.

Best Practices for a Config File

• Avoid making changes to pages or assemblies that are there in the bin directory of the application. A changed page will only recompile the page. Any change to the bin directory will result in recompilization of the entire application.


• The config file is configured to enable the widest set of features. For a performance boost it is better to tune it to the requirements. Some key points here are:
• Encoding - Request/Response - The default is UTF-8 encoding. If the site is completely ASCII, change the option to ASCII encoder.


• Session State - By default is ON. If session state is not maintained then the value should be changed to OFF.


• ViewState - Default is ON. Turn it off if not being used. If ViewState is being used there are different levels of security that need to considered which can impact the performance of the application.


• AutoEventWireup - Turning off AutoEventWireup means that the page will not try and match up method names to events and hook them up (i.e. Page_Load, etc). Instead, if the application writer wishes to receive them, they need to override the methods in the base class (i.e. override OnLoad for the page load event instead of using a Page_Load method). By doing so, the page will get a slight performance boost by not having to do the extra work itself, but leaving it to the page author.
• For efficient debugging Use ASP.NET trace feature to debug instead of Response.Write

Conclusion