Web application performance guidelines

Introduction

When you design and develop your web applications, you always must take into consideration the performance factor. By doing this, you will remove the cost of rewriting modules, modifying code, or redistributing applications. A good practice that must be kept in mind for writing quality code is to make frequent code reviews. For example, I often find a better implementation of a certain module after a code review. Also, you should test different ways of implementing your code to determine the performance impact over your application. Here are some rules that should be followed for writing high performing applications.

The rules

1. Store your content by using caching

As you know, ASP.NET allows you to cache entire pages, fragments of pages, or controls. You can also cache variable data by specifying the parameters that the data depends on. By using caching, you help the ASP.NET engine to return data for repeated requests for the same page much faster. There is one catch here: caching consumes server memory, so it's not recommended to be used when you need to get updated data on your page.

2. Avoid session state

Whether you store your data in in-process or on a state server or in a SQL database, session state requires memory, and it's also time consuming when you store or retrieve data from it. If you do not want to use session state, disable it on your web form using the <@%Page EnableSessionState="false"%> directive. In case you use session state only to retrieve data from it and not to update it, make the session state read only by using the <@%Page EnableSessionState ="ReadOnly"%> directive.

3. Avoid ViewState

ViewState allows you to keep the content of a control across trips to the server. This comes with a cost, a greater amount of data is sent from the server to the client end vice versa, so speed and network bandwidth can be affected. You can avoid this drawback by setting the EnableViewState property of your web controls to false, when you don't need them to keep their state across server trips.

4. Use low cost authentication

Authentication can also have an impact over the performance of your application. For example, passport authentication is slower than form-based authentication, which in turn is slower than Windows authentication.

5. Use the Server.Transfer() method for server-side page redirection

It is better to use the Server.Transfer() method for server-side ASPX page redirection in the same application than the Response.Redirect() method. This will reduce the extra roundtrip required by the second method (Response.Redirect()) to perform client-side redirection.

6. The number of web server controls

The use of web server controls increases the response time of your application because they need time to be processed on the server side before they are rendered on the client side. Therefore, take into consideration the usage of HTML elements where they are suited, for example, if you want to display static text.

7. Avoid frequent usage of boxing and unboxing

When a value type such as a structure is copied to a reference type such as a class, the compiler creates an object on the heap and copies the value of the value type from the stack to this newly created object on the heap. This process is called boxing, and requires more overhead than just a simple copy from a value type to value type. When you copy a reference type to a value type, the value of the object from the heap is copied to the value type from the stack. This process is called unboxing. You should take into consideration the overhead of these processes when you design your application.

8. Avoid using strings for complex string operations

The String type is immutable; this means that after a string is created, it can't be modified. When you modify a string, the CLR creates a new one based on your modifications and returns it. The old string remains in memory until the garbage collector cleans it. If your application needs to extensively modifying strings, then use the StringBuilder class. This class stores the string as an array of characters. The StringBuilder object is mutable, and does in-place modifications of strings.

9. Use the AddRange() method with collections

There is a large number of collection classes that expose the AddRange() method, which you can use to add an array of items to the collection instead of repeatedly calling the Add() method inside a loop.

10. Avoid throwing exceptions

Throwing exceptions is a costly operation. You should be very careful when you throw exceptions from your application. Exceptions should be thrown only to signify an exceptional error case. You should never throw exceptions just for managing your application flow.

11. Avoid using unmanaged code

Calls to unmanaged code are a costly marshaling operation. Try to reduce the number of calls between managed and unmanaged code. Consider doing more work in each call rather than making frequent calls to do small tasks.

12. Avoid making frequent calls across processes

Working with distributed applications involves additional overhead negotiating network and application level protocols. In this case, network speed can also be a bottleneck. Try to do as much work as possible in fewer calls over the network.

13. Make use of optimized managed providers

As you know, OLEDB is a generic provider which offers access to data exposed by any OLEDB provider. Managed providers are specifically optimized for some databases. For example, when you use OLEDB to connect to a SQL Server database, OLEDB first passes your request to OLE DB COM components, which in turn translate the request to the SQL Native Tabular Data Stream (TDS) format. If you use SqlClient, it will directly construct the TDS packets and communicate with SQL Server. The removal of extra translation will significantly improve the performance of your application.

14. Use Stored Procedure and not SQL statements

When you are working with an RDBMS as SQL Server, you should use Stored Procedures rather than SQL statements given as a text command, because Stored Procedures are highly optimized for server side data access.

15. Use a DataReader instead of a DataSet for forward-only sequential access

If you are reading a table sequentially, you should use the DataReader rather than the DataSet. A DataReader object creates a read only stream of data that will increase your application performance because only one row is in memory at a time.

16. Use connection pooling

The slowest operation performed in a database application scenario is establishing a connection with a database. The SQL Server .NET Data Provider offers 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. If you are using dynamic connection strings, you will disallow the connection pooling mechanism because connections are only pooled on the exact connection string.

17. Use transactions

Distributed transactions might add performance overhead to your application, so you should use them only when required and keep their life as short as possible.