CodeVerge.Net Beta


   Explore    Item Entry   Register  Login  
Microsoft News
Asp.Net Forums
IBM Software
Borland Forums
Adobe Forums
Novell Forums




Can Reply:  No Members Can Edit: No Online: Yes
Zone: > NEWSGROUP > Asp.Net Forum > general_asp.net.faq_frequently_asked_questions Tags:
Item Type: NewsGroup Date Entered: 8/7/2006 2:03:08 PM Date Modified: Subscribers: 0 Subscribe Alert
Rate It:
NR
XPoints: N/A Replies: 0 Views: 103 Favorited: 0 Favorite
1 Items, 1 Pages 1 |< << Go >> >|
ranganh
Asp.Net User
ASP.NET 2.0 Performance Tuning Considerations8/7/2006 2:03:08 PM

0

ASP.NET 2.0 in general has a lot of performance enhancement features starting from compilation model to ADO.NET 2.0 DataSets which is comparitively faster than its predecessor. Please check New DataSet Features in ADO.NET 2.0 for more information.

Herebelow are some of the performance considerations I have observed after digging dirty with performance tuning ASP.NET 2.0 Applications.

Paging through Records
Always use Custom Paging and dont rely on the default built-in paging mechanism for GridView, DataGrid etc.,

Please check my earlier articles on custom paging

Using Cache / Session Objects

Using SQL Server

Turn off Session State
ASP.NET uses a built-in session state mechanism as well as supports your Custom Session State model. However, the cost of Session storage becomes heavy when the users, objects stored increase significantly. Turn off Session State for pages which dont require Session. Typically in a web application there may be static as well as dynamic pages. In the static pages, which dont require Session, the Session State can be turned off. Wherever, you just require Session Data as ReadOnly (where you wont be updating the Session Data), the SessionState can be made ReadOnly.

To turn off Session State at page level,

<%@ Page EnableSessionState="False" %>

To make it ReadOnly at page level,

<%@ Page EnableSessionState="ReadOnly" %>

If your Website has a lot of content pages which are static and only certain pages require Session Data, try considering Turning off SessionState at the Web.Config level and only enable it for those pages which require Session Data. Always the Page settings will override the web.config settings. Session State can be turned off in the web.config as follows:-

<pages enableSessionState="false"></pages>

Turn off View State
View State is the wonderful mechanism which stores the page as well as controls' data, state etc., across round trips. However, the View State can grow heavy significantly increasing the load and hence, View State must be turned off for pages which dont require the same. ViewState can be turned off at page level as follows:-


<%@ Page EnableViewState="False" %>


Use Caching
Cache your pages wherever possible. When implementing OutputCache, set a longer duration than setting a shorter duration. A longer duration Cache is much more better than quick short duration caches.

When the content of page can change, try using Cache with Dependency. There are various dependency techniques such as FileDependency, Database Dependency etc., to invalidate the cache.

Use IsPostBack
The IsPostBack is your best friend in controlling when to load the controls, populate data. ASP.NET, by default postbacks to the server for any/all operations and the number of Page_Loads you would be having will be significant. When using IsPostBack, it validates that the DataBinding methods are called only the first time the page loads and not for subsequent PostBacks.

if(!IsPostBack)
{
// Data Bind your Controls
}

Use DataSources
The Provider model and the DataSource controls in ASP.NET 2.0 not only simplify the Data Binding techniques but also provide significant performance enhancements by caching the Data as well as reducing the number of DB hits required to populate similar data on different controls. The Provider model eliminates the Control from the underlying Data Model thereby making it a thin layer which just represents whatever is bound to it.

When using SqlDataSource, ObjectDataSource etc., an important point to note is that, you dont need to bind the Data explicitly to the controls using DataBind.Ex.-

GridView1.DataSourceId = SqlDataSource1 // where SqlDataSource1 is the ID of the Datasource control.

That is all required. You dont require the GridView1.DataBind(); method which we are very familiar from .NET 1.0. The reason is that, the DataBind method is implicitly called by the EnsureDataBound method of the DataSource control. If we call it explicitly, then it results in a double binding of Data.

regards,
Harish

http://geekswithblogs.net/ranganh
1 Items, 1 Pages 1 |< << Go >> >|


Free Download:




   
  Privacy | Contact Us
All Times Are GMT