Designing a Web Application for Performance

You should plan for performance early in the development cycle of an application. It is inexpensive to remove any performance glitches early in the development cycle. As the application moves beyond design, the cost of modifying code or redistributing an application goes up.

The following list includes some of the commonly acknowledged best practices for developing high-performing applications using the .NET Framework:

• Use caching to store content ” ASP.NET enables you to cache entire pages, fragments of pages, or controls. You can also cache variable data by specifying the parameters on which the data depends. Using caching makes it quicker for ASP.NET to return data in response to repeated requests for the same page. On the downside, caching consumes memory. Caching is also not recommended when the application needs to always retrieve the most recent data.

• Avoid session state ” Whether you store it in process, in a State Server, or in a SQL Server database, session state takes memory and requires processing time to store and retrieve values. If a Web form doesn't depend on session state, disable the session state with the <@% PageEnableSessionState="false" %> directive. If a Web form only retrieves data but does not update the session state, make the session state read-only with the <@% Page EnableSessionState="ReadOnly" %> directive.

• Avoid view state ” View state lets you persist the contents of a control across trips between the client and server. This comes at the cost of additional bytes traveling in each direction and hence imposes a speed hit. You can avoid this penalty by setting the EnableViewState property of controls to false when you don't need the control's contents to persist.

• Use low-cost authentication ” Passport authentication is slower than forms-based authentication, which is slower than Windows authentication. Not authenticating users at all is the fastest choice.

• Use ASP.NET tracing to know the performance of the Web page ” Tracing provides information on the Web form control tree structure; the size of the view state for each control; different stages of the page processing; and the timing in each of the stages, headers, form variables, sessions and cookies, server variables , and so on. Furthermore, you can include debug messages. Therefore, this great amount of information can be very helpful in knowing the performance of a Web page.

• Use the Server.Transfer() method for server-side page redirection ” You should prefer to use the Server.Transfer() method for server-side redirection to ASPX pages in the same application over the Response.Redirect() method. This reduces the extra round trip required by the Response.Redirect() method to perform client-side redirection.

• Use Web server controls wisely ” Web server controls need to be processed on the server before they are rendered to the client. Therefore, when the programmable features of the Web form controls are not used, their usage should be avoided. For example, if you place a Label Web control on the page that only displays static text and is never used in the server-side code, you should place static HTML text in place of the Label Web server control.

• Avoid frequent boxing and unboxing ” When a value type (such as a structure) is copied to a reference type (such as a class), the compiler needs to create an object on the heap and copy the value of the value type from the stack to this newly created object on the heap. This process is called boxing . On the other hand, when you copy a reference type to a value type, the value of the object from the heap is copied to the value type in the stack. This process is called unboxing . You should be aware of the overhead involved in boxing and unboxing, and while designing the application, you should choose appropriate data types to minimize this overhead.

• Use the StringBuilder class for complex string concatenations and manipulations ” If an application is extensively modifying strings, you should consider using the System.Text.StringBuilder class, which stores the string as an array of characters . The StringBuilder object is mutable and does in-place modification of strings.

• Use AddRange() with collections ” A large number of collection classes provide the AddRange() method, which you can use to add an array of items to the collection. Using AddRange() is much faster than adding elements by repeatedly calling the Add() method inside a loop.

• Be careful about throwing exceptions ” Exceptions are cheap, until you throw one using the throw statement. Throwing exceptions is a costly operation. You should use them only to signify exceptional error cases. You should not use exceptions just to manage normal program flow.

• Avoid using unmanaged code ” Calls to unmanaged components involve costly marshaling operations; therefore, the performance of these programs might deteriorate. For maximum performance, you should rewrite the unmanaged components by using one of the languages supported by the CLR. If a rewrite is not possible, you should monitor the use of the unmanaged component to see whether you can reduce the number of calls between the managed and unmanaged code, possibly by doing more work in each call rather than by making frequent calls to do small tasks .

• Make fewer calls across processes ” Working with distributed applications involves the additional overhead of negotiating network- and application-level protocols. Network speed can also be a bottleneck. The best approach is to get more done with fewer calls across the network.

• Compile the application by using the Release configuration ” When you are ready to deploy an application, compile it in Release mode rather than in the default Debug mode. Applications compiled using Debug mode might run slowly because of the presence of extra debugging code.

• Use the optimized managed providers ” System.Data.OleDb is a generic provider that can access data exposed by any OleDb provider. Managed providers are specifically optimized for some databases. So, if you are connecting to a SQL Server database, you should use System.Data.SqlClient instead of the generic System.Data.OleDb . Similarly, for Oracle databases you should use classes from the System.Data.OracleClient namespace.

• Use stored procedures instead of SQL statements ” When working with an RDBMS such as SQL Server, you should use stored procedures rather than a set of SQL statements given as a text command because stored procedures are highly optimized for server-side data access and their use usually improves data access performance significantly.

• Tune the database ” Keeping up-to-date indexes greatly helps in improving performance for a database- intensive Web application. You can run SQL Server's Profiler and Index Tuning Wizard to avoid any bottlenecks caused by indexing. In addition, you can use the SQL Server Query Analyzer to optimize a query's performance.

• Use DataReader instead of DataSet for forward-only sequential access ” If you are reading a table sequentially, you should use DataReader rather than DataSet . DataReader creates a read-only, forward-only stream of data that increases application performance and reduces system overhead because only one row is in memory at a time.

• Use connection pooling for the SQL Server .NET data provider ” The slowest database operation is establishing a connection with the database. The SQL Server .NET Data Provider provides connection pooling to improve performance when connecting to a SQL Server database. In connection pooling, old connection information is stored in a connection pool so it can be reused for the next connection. Making fewer new connections with each request provides significant performance gains. However, if you have dynamic connection strings (that is, you change parameters of the connection strings), you will effectively disallow connection pooling because connections are pooled only on the exact connect string (even whitespaces need to match). To maximize the reuse of connections in a connection pool, you must use the same connection string for all the connections.

• Avoid using auto-generated commands ” The SqlCommandBuilder and OleDbCommandBuilder classes enable you to automatically generate commands used to reconcile changes made to a DataSet. Although automatic generation of INSERT , UPDATE , and DELETE statements for changes to a dataset makes database updates very convenient , it also requires extra trips to the server to get the schema information. Therefore, you should make convenience and performance trade-offs depending on the application's requirements.

• Use short-lived transactions ” Distributed transactions might have significant performance overhead. As a rule of thumb, you should use transactions only when required and keep the transactions as short-lived as possible.