The following guidelines
list specific techniques that you can use to avoid writing code that does not perform at
•Disable session state
when you are not using it. Not all applications or pages require
per-user session state, and you
should disable it for any that do not.
To disable session state
for a page, set the EnableSessionState attribute in the @ Page
directive to false.
<%@ Page EnableSessionState="false" %>.
Note: 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.
Session state can also be
disabled for XML Web service methods..
To disable session state
for an application, set the mode attribute to off in the session state configuration section in
the application’s Web.config file.
<sessionstate mode="off" />.
session-state provider carefully. ASP.NET provides three distinct
ways to store session data for your
In-process session state, out-of-process session state
as a Windows service, and
out-of-process session state in a SQL Server database. Each has it advantages, but
in-process session state is by far the fastest solution. If you are
storing only small amounts of volatile
data in session state, it is recommended that you use the in-process provider.
out-of-process solutions are useful primarily if you scale your
application across multiple processors or
multiple computers, or where data cannot be lost if a server or
process is restarted.
round trips to the server. While it is tempting to use the time- and code-saving features of
the Web Forms page framework as much as you can, there are
circumstances in which using ASP.NET
server controls and postback event handling are inappropriate. Typically, you need to
initiate round trips to the server only when your application is retrieving or storing
data. Most data manipulations can take place on the client between
these round trips.
validating user input from HTML forms can often take place on the client before that data
is submitted to the server. In general, if you do not need to relay information to the server
to be stored in a database, you should not write code that causes a round trip.
If you develop custom
server controls, consider having them render client-side code for
browsers that support ECMAScript.
By using server controls in this way, you can dramatically reduce the number of times
information is unnecessarily sent to the Web server.
Use Page.IsPostBack to
avoid performing unnecessary processing on a round trip. If you write
code that handles server
control postback processing, you will sometimes want other code to
execute the first time the page
is requested, rather than the code that executes when a user posts an HTML form contained in
the page. Use the Page.IsPostBack property to conditionally execute
code depending on whether the
page is generated in response to a server control event.
•Leave buffering on
unless you have a specific reason to turn it off. There is a
significant performance cost for
disabling buffering of Web Forms pages.
•Do not rely on
exceptions in your code. Since exceptions 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. 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
HttpServerUtility.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.
•Make all modules in
the request pipeline as efficient as possible. All modules in the
request pipeline will have a
chance to be run on each request. Therefore, it is vital that the
code triggered when a request
enters and leaves each module executes quickly, especially in a code path where the module’s
feature is not used. Performing throughput tests with and without the modules and profiles is
very useful in determining how fast these methods are executing.
•Use SQL Server stored
procedures for data access. Of all the data access methods provided
by the .NET Framework, SQL
Server–based data access is the recommended choice for building high-performance,
scalable Web applications. When using the managed SQL Server
provider, you can get an additional
performance boost by using compiled stored procedures instead of ad
•Use the SqlDataReader
class for a fast forward-only data cursor. The SqlDataReader class provides a means to read
a forward-only data stream retrieved from a SQL Server database. If situations arise while
you are creating an ASP.NET application that allow you to use it, theSqlDataReader class
offers higher performance than the DataSet class. This is the case
because SqlDataReader uses SQL
Server’s native network data-transfer format to read data directly
from a database connection.
Also, the SqlDataReader class implements the IEnumerable interface,
which allows you to bind data
to server controls as well.
•Choose the data
viewing mechanism appropriate for your page or application. Depending
on how you choose to display data in
a Web Forms page, there are often significant tradeoffs betweenconvenience and
performance. For example, the DataGrid Web server 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
•Cache data and page
output whenever possible. ASP.NET provides simple mechanisms for
caching page output or data when
they do not need to be computed dynamically for every page request.
In addition, designing pages
and data requests to be cached, particularly in areas of your site where you expect heavy
traffic, can optimize the performance of those pages. More than any feature of the .NET
Framework, using the cache appropriately can affect the performance
of your site, sometimes by more
than an order of magnitude.
There are two caveats to
using the ASP.NET caching mechanisms.
First, do not cache too
many items. There is a cost for caching each item, especially in
memory utilization. Items that are easily recalculated or rarely used
should not be cached. Second, do not assign cached items a short
expiration. Items that expire quickly cause unnecessary turnover in
the cache and frequently cause more
work for cleanup code and the garbage collector. If this is a
concern, monitor the Cache Total
Turnover Rate performance counter associated with the ASP.NET Applications performance
object. A high turnover rate could indicate a problem, especially
when items are removed before
their expiration. This is also known as memory pressure.
•Be sure to disable
debug mode. Always remember to disable debug mode before deploying a production application or
conducting any performance measurements. If debug mode is enabled,
the performance of your
application can suffer a great deal. For syntax information about
setting the debug mode for your
application in the Web.config file, see ASP.NET Settings Schema.
•Tune the configuration
files for your Web server computer and specific applications to suit
your specific needs.
default the ASP.NET configuration is set to enable the widest set of
features and try to accommodate
most common scenarios. As such, some of these can be tuned and
changed depending on the features
used by the app developer to improve the performance of applications.