Introduction
This
article gives a simple checklist that can simply be run against any ASP .NET Web
Page to optimize it. This is in no way a complete list, however it should work
for most of the web pages. For a performance critical application you will
surely need to go beyond this checklist and will require a more detailed plan.
Checklist for all pages
Here
is the list of checks that you need to run, not necessarily in order:
- Disable
ViewState
- Set "EnableViewState=false" for any control that does not need
the view state. As a general rule if your page does not use postback, then
it is usually safe to disable viewstate for the complete page itself.
- Use
Page.Ispostback is used in Page_Load - Make sure that all code
in page_load is within "if( Page.Ispostback)" unless it
specifically needs to be executed upon every Page Load.
- Asynchronous
calls for Web Services - If you are using Web Services in you page
and they take long time to load, then preferably use Asynchronous calls to
Web Services where ever applicable and make sure to wait for end of the
calls before the page is fully loaded. But remember Asynchronous calls
have their own overheads, so do not overdo it unless needed.
- Use String
Builder for large string operations - For any long string operations,
use String Builder instead.
- Specialized
Exception Handling - DO not throw exceptions unless needed, since
throwing an exception will give you a performance hit. Instead try
managing them by using code like "if not system.dbnull �." Even you if you have
to handle an exception then de-allocate any memory extensive object within
"finally" block. Do not depend on Garbage Collector to do the
job for you.
Collapse
//
// Try
// 'Create Db Connection and call a query
// sqlConn = New
SqlClient.SqlConnection(STR_CONN)
// Catch ex As Exception
// 'Throw any Error that occurred
// Throw ex
// Finally
// 'Free Database connection objects
// sqlConn = Nothing
//End Try
//
- Leave Page
Buffering on
- Leave Page buffering On, unless specifically required so. Places where
you might require to turn it on in case of very large pages so that user
can view something while the complete page is loading.
- Use Caching - Cache
Data whenever possible especially data which you are sure won't change at
all or will be reused multiple times in the application. Make sure to have
consistent cache keys to avoid any bugs. For simple pages which do not
change regularly you can also go for page Caching
Collapse
//
// <% @OutputCache
Duration="60" VaryByParam="none" %>
//
Learn more about "VaryByParam" and
"VaryByControl" for best results.
- Use Script
files
- As a rule unless required do not insert JavaScript directly into any
page, instead save them as script file ".js" and embed them. The
benefit being that common code can be shared and also once a script file
is loaded into browser cache, it is directly picked up from browser cache
instead of downloading again.
- Remove
Unused Javascript - Run through all Javascript and make sure
that all unused script is removed.
- Remove
Hidden HTML when using Tabstrip - In you are using a Tabstrip
control and if the HTML size is too large and the page does frequent
reloads, then turn Autopostback of Tabstrip on, put each Pageview inside a
panel and turn visibility of all Panels except the current one to False.
This will force the page to reload every time a tab is changed however the
reload time will reduce heavily. Use your own jurisdiction to best use.
Additional Checklist for performance
critical pages
- Disable
session when not using it - If your page does not use
session then disable session specifically for that page.
Collapse
//
// <%@ Page
EnableSessionState="false" %>
//
If the page only reads session but does not write
anything in session, then make it read only.
Collapse
//
// '<%@ Page
EnableSessionState="ReadOnly" %>
//
- Use Option
Strict On (VB .Net only) - Enabling Option Script restricts
implicit type conversions, which helps avoid those annoying type
conversion and also is a Performance helper by eliminating hidden
type conversions. I agree it takes away some of you freedom, but believe
me the advantages outweigh the freedom.
- Use
Threading
- When downloading huge amounts of data use Threading to load Data in
background. Be aware, however, that threading does carry overhead and must
be used carefully. A thread with a short lifetime is inherently
inefficient, and context switching takes a significant amount of execution
time. You should use the minimum number of long-term threads, and switch
between them as rarely as you can.
- Use Chunky
Functions
- A chunky call is a function call that performs several tasks. you should
try to design your application so that it doesn't rely on small, frequent
calls that carry so much overhead.
- Use Jagged
Arrays
- In case you are doing heavy use of Multi Dimensional Arrays, use Jagged
Array ("Arrays of Arrays") Instead
- Use
"&" instead of "+" - You should use the
concatenation operator (&) instead of the plus operator (+) to
concatenate strings. They are equivalent only if both operands are of type
String. When this is not the case, the + operator becomes late bound and
must perform type checking and conversions.
- Use Ajax - In
performance critical application where there are frequent page loads,
resort to Ajax.
- Use the
SqlDataReader class - The SqlDataReader class provides a means to
read forward-only data stream retrieved from a SQL Server� database. If you only need
to read data then SqlDataReader class offers higher performance than the
DataSet class because SqlDataReader uses the Tabular Data Stream protocol
to read data directly from a database connection
- Choose
appropriate Session State provider - In-process session state is the
fastest solution. If you store only small data in session state, go for
in-process provider. The out-of-process solutions is useful if you scale
your application across multiple processors or multiple computers.
- Use Stored
Procedures
- Stored procedures are pre-compiled and hence are much faster than a
direct SQL statement call.
- Use Web
Services with care - Web Services depending on data volume can
have monstrous memory requirements. Do not go for Web Services unless your
Business Models demands it.
- Paging in
Database Side -
When you needs to display large amount of Data to the user, go for a
stored procedure based Data Paging technique instead of relying on the
Data Grid/ Data List Paging functionality. Basically download only data for
the current page.