Introduction
ASP.NET is much more powerful than classic ASP, however it is important to understand how to use that power to build highly efficient, reliable and robust applications. In this article, I tried to highlight the key tips you can use to maximize the performance of your ASP.NET pages. The list can be much longer, I am only emphasizing the most important ones.
1. Plan and research before you develop
Research and investigate how .NET can really benefit you. .NET offers a variety of solutions on each level of application design and development. It is imperative that you understand your situation and pros and cons of each approach supported by this rich development environment. Visual Studio is a comprehensive development package and offers many options to implement the same logic. It is really important that you examine each option and find the best optimal solution suited for the task at hand. Use layering to logically partition your application logic into presentation, business, and data access layers. It will not only help you create maintainable code, but also permits you to monitor and optimize the performance of each layer separately. A clear logical separation also offers more choices for scaling your application. Try to reduce the amount of code in your code-behind files to improve maintenance and scalability.
2. String concatenation
If not handled properly, String Concatenation can really decrease the performance of your application. You can concatenate strings in two ways.
- First, by using string and adding the new string to an existing string. However, this operation is really expensive (especially if you are concatenating the string within a loop). When you add a string to an existing string, the Framework copies both the existing and new data to the memory, deletes the existing string, and reads data in a new string. This operation can be very time consuming and costly in lengthy string concatenation operations.
- The second and better way to concatenate strings is using the
StringBuilder
Class. Below is an example of both approaches. If you are considering doing any type of String Concatenation, please do yourself a favor and test both routines separately. You may be surprised at the results.
Response.Write("<b>String Class</b>")
Dim str As String = ""
Dim startTime As DateTime = DateTime.Now
Response.Write(("<br>Start time:" + startTime.ToString()))
Dim i As Integer
For i = 0 To 99999
str += i.ToString()
Next i
Dim EndTime As DateTime = DateTime.Now
Response.Write(("<br>End time:" + EndTime.ToString()))
Response.Write(("<br># of time Concatenated: " + i.ToString))
Results: Took 4 minutes and 23 Seconds to to complete 100,000 Concatenations.
String
Class
- Start time: 2/15/2006 10:21:24 AM
- End time: 2/15/2006 10:25:47 AM
- # of time Concatenated: 100000
Response.Write("<b>StringBuilder Class</b>")
Dim strbuilder As New StringBuilder()
Dim startTime As DateTime = DateTime.Now
Response.Write(("<br>Start time:" + startTime.ToString()))
Dim i As Integer
For i = 0 To 99999
strbuilder.Append(i.ToString())
Next i
Dim EndTime As DateTime = DateTime.Now
Response.Write(("<br>Stop time:" + EndTime.ToString()))
Response.Write(("<br># of time Concatenated: " + i.ToString))
Results: Took less than a Second to complete 100,000 Concatenations.
StringBuilder
Class
- Start time: 2/15/2006 10:31:22 AM
- Stop time:2/15/2006 10:31:22 AM
- # of time Concatenated: 100000
This is one of the many situations in which ASP.NET provides extremely high performance benefits over classic ASP.
3. Avoid round trips to the server
You can avoid needless round trips to the Web Server using the following tips:
4. Save viewstate only when necessary
ViewState
is used primarily by Server controls to retain state only on pages that post data back to themselves. The information is passed to the client and read back in a hidden variable. ViewState
is an unnecessary overhead for pages that do not need it. As the ViewState
grows larger, it affects the performance of garbage collection. You can optimize the way your application uses ViewState
by following these tips:
Situation when you don't need ViewState
ViewState
is turned on in ASP.NET by default. You might not need ViewState
because your page is output-only or because you explicitly reload data for each request. You do not need ViewState
in the following situations:
- Your page does not post back. If the page does not post information back to itself, if the page is only used for output, and if the page does not rely on response processing, you do not need ViewState.
- You do not handle server control events. If your server controls do not handle events, and if your server controls have no dynamic or data bound property values, or they are set in code on every request, you do not need
ViewState
.
- You repopulate controls with every page refresh. If you ignore old data, and if you repopulate the server control each time the page is refreshed, you do not need
ViewState
.
Disabling viewstate
There are several ways to disable ViewState
at various levels:
- To disable
ViewState
for a single control on a page, set the EnableViewState
property of the control to false
.
- To disable
ViewState
for a single page, set the EnableViewState
attribute in the @ Page
directive to false
. i.e.
<%@ Page EnableViewState="false" %>
- To disable
ViewState
for a specific application, use the following element in the Web.config file of the application:
<pages enableViewState="false" />
- To disable
ViewState
for all applications on a Web server, configure the <pages>
element in the Machine.config file as follows:
<pages enableViewState="false" />
Determine the size of your ViewState
By enabling tracing for the page, you can monitor the ViewState
size for each control. You can use this information to determine the optimal size of the ViewState
or if there are controls in which the ViewState
can be disabled.
5. Use session variables carefully
Avoid storing too much data in session variables, and make sure your session timeout is reasonable. This can use a significant amount of server memory. Keep in mind that data stored in session variables can hang out long after the user closes the browser. Too many session variables can bring the server on its knees. Disable session state, if you are not using session variables in the particular page or application.
- To disable session state for a page, set the
EnableSessionState
attribute in the @ Page
directive to false
.i.e.
<%@ Page EnableSessionState="false" %>
- If a page requires access to session variables but will not create or modify them, set the
EnableSessionState
attribute in the@ Page
directive to ReadOnly
. i.e.
<%@ Page EnableSessionState="ReadOnly" %>
- To disable session state for a specific application, use the following element in the Web.config file of the application.
<sessionState mode='Off'/>
- To disable session state for all applications on your Web server, use the following element in the Machine.config file:
<sessionState mode='Off'/>
6. Use Server.Transfer
Use the Server.Transfer
method to redirect between pages in the same application. Using this method in a page, with Server.Transfer
syntax, avoids unnecessary client-side redirection. Consider Using Server.Transfer
Instead of Response.Redirect
. However, you cannot always just replace Response.Redirect
calls with Server.Transfer
. If you need authentication and authorization checks during redirection, use Response.Redirect
instead of Server.Transfer
because the two mechanisms are not equivalent. When you use Response.Redirect
, ensure you use the overloaded method that accepts a Boolean second parameter, and pass a value of false
to ensure an internal exception
is not raised. Also note that you can only use Server.Transfer
to transfer control to pages in the same application. To transfer to pages in other applications, you must use Response.Redirect
.
7. Use server controls when appropriate and avoid creating deeply nested controls
The HTTP protocol is stateless; however, server controls provide a rich programming model that manage state between page requests by using ViewState
. However nothing comes for free, server controls require a fixed amount of processing to establish the control and all of its child controls. This makes server controls relatively expensive compared to HTML controls or possibly static text. When you do not need rich interaction, replace server controls with an inline representation of the user interface that you want to present. It is better to replace a server control if:
- You do not need to retain state across postbacks
- The data that appears in the control is static or control displays read-only data
- You do not need programmatic access to the control on the server-side
Alternatives to server controls include simple rendering, HTML elements, inline Response.Write
calls, and raw inline angle brackets (<% %>
). It is essential to balance your tradeoffs. Avoid over optimization if the overhead is acceptable and if your application is within the limits of its performance objectives.
Deeply nested hierarchies of controls compound the cost of creating a server control and its child controls. Deeply nested hierarchies create extra processing that could be avoided by using a different design that uses inline controls, or by using a flatter hierarchy of server controls. This is especially important when you use controls such as Repeater
, DataList
, and DataGrid
because they create additional child controls in the container.
8. Choose the data viewing control appropriate for your solution
Depending on how you choose to display data in a Web Forms page, there are often significant tradeoffs between convenience and performance. Always compare the pros and cons of controls before you use them in your application. For example, you can choose any of these three controls (DataGrid
, DataList
and Repeater
) to display data, it's your job to find out which control will provide you maximum benefit. The DataGrid
control can be a quick and easy way to display data, but it is frequently the most expensive in terms of performance. Rendering the data yourself by generating the appropriate HTML may work in some simple cases, but customization and browser targeting can quickly offset the extra work involved. A Repeater
Web server control is a compromise between convenience and performance. It is efficient, customizable, and programmable.
9. Optimize code and exception handling
To optimize expensive loops, use For
instead of ForEach
in performance-critical code paths. Also do not rely on exception
s in your code and write code that avoids exception
s. Since exception
s cause performance to suffer significantly, you should never use them as a way to control normal program flow. If it is possible to detect in code a condition that would cause an exception
, do so. Do not catch the exception
itself before you handle that condition. Do not use exception
s to control logic. A database connection that fails to open is an exception
but a user who mistypes his password is simply a condition that needs to be handled. Common scenarios include checking for null
, assigning a value to a String
that will be parsed into a numeric value, or checking for specific values before applying math operations. The following example demonstrates code that could cause an exception
and code that tests for a condition. Both produce the same result.
Try
value = 100 / number
Catch ex As Exception
value = 0
End Try
If Not number = 0 Then
value = 100 / number
Else
value = 0
End If
Check for null
values. If it is possible for an object to be null
, check to make sure it is not null
, rather then throwing an exception
. This commonly occurs when you retrieve items from ViewState
, session state, application state, or cache objects as well as query string and form field variables. For example, do not use the following code to access session state information.
Try
value = HttpContext.Current.Session("Value").ToString
Catch ex As Exception
Response.Redirect("Main.aspx", False)
End Try
If Not HttpContext.Current.Session("Value") Is Nothing Then
value = HttpContext.Current.Session("Value").ToString
Else
Response.Redirect("Main.aspx", False)
End If
10. Use a DataReader for fast and efficient data binding
Use a DataReader
object if you do not need to cache data, if you are displaying read-only data, and if you need to load data into a control as quickly as possible. The DataReader
is the optimum choice for retrieving read-only data in a forward-only manner. Loading the data into a DataSet
object and then binding the DataSet
to the control moves the data twice. This method also incurs the relatively significant expense of constructing a DataSet
. In addition, when you use the DataReader
, you can use the specialized type-specific methods to retrieve the data for better performance.
11. Use paging efficiently
Allowing users to request and retrieve more data than they can consume puts an unnecessary strain on your application resources. This unnecessary strain causes increased CPU utilization, increased memory consumption, and decreased response times. This is especially true for clients that have a slow connection speed. From a usability standpoint, most users do not want to see thousands of rows presented as a single unit. Implement a paging solution that retrieves only the desired data from the database and reduces back-end work on the database. You should optimize the number of rows returned by the Database Server to the middle-tier web-server. For more information read this article to implement paging at the Database level. If you are using SQL Server 2000, please also look at this article.
12. Explicitly Dispose or Close all the resources
To guarantee resources are cleaned up when an exception occurs, use a try
/finally
block. Close the resources in the finally
clause. Using a try
/finally
block ensures that resources are disposed even if an exception
occurs. Open your connection just before needing it, and close it as soon as you're done with it. Your motto should always be "get in, get/save data, get out." If you use different objects, make sure you call the Dispose
method of the object or the Close
method if one is provided. Failing to call Close
or Dispose
prolongs the life of the object in memory long after the client stops using it. This defers the cleanup and can contribute to memory pressure. Database connection and files are examples of shared resources that should be explicitly closed.
Try
_con.Open()
Catch ex As Exception
Throw ex
Finally
If Not _con Is Nothing Then
_con.Close()
End If
End Try
13. Disable tracing and debugging
Before you deploy your application, disable tracing and debugging. Tracing and debugging may cause performance issues. Tracing and debugging are not recommended while your application is running in production. You can disable tracing and debugging in the Machine.config and Web.config using the syntax below:
<configuration>
<system.web>
<trace enabled="false" pageOutput="false" />
<compilation debug="false" />
</system.web>
</configuration>
14. Precompile pages and disable AutoEventWireup
By precompiled pages, users do not have to experience the batch compile of your ASP.NET files; it will increase the performance that your users will experience.
In addition, setting the AutoEventWireup
attribute to false
in the Machine.config file means that the page will not match method names to events and hook them up (for example, Page_Load
). If page developers want to use these events, they will need to override the methods in the base class (for example, they will need to override Page.OnLoad
for the page load event instead of using a Page_Load
method). If you disable AutoEventWireup
, your pages will get a slight performance boost by leaving the event wiring to the page author instead of performing it automatically.
15. Use stored procedures and indexes
In most cases you can get an additional performance boost by using compiled stored procedures instead of ad hoc queries.
Make sure you index your tables, and choose your indexes wisely. Try using Index Tuning Wizard and have it report to you what it thinks the best candidates for indexes would be. You don't have to follow all of its suggestions, but it may reveal things about your structure or data that will help you choose more appropriate indexes.
- In SQL Server Management Studio (SQL Server 2005), highlight your query. Now from the Query menu, click Analyze Query in Database Engine Tuning Advisor.
- You can do something similar in SQL Server 2000 to run the index tuning wizard? In Query Analyzer, highlight your query. From the Query menu, click Index Tuning Wizard.
References