ASP.NET Best Practices

Harish Ranganathan Web Developer Evangelist Microsoft Corporation India

• Web Application Security – Quick Tips • Performance Overview • Performance Improvements in .NET 2. • Performance when developing • Performance when deploying • Results of a Few Performance Tests

• ValidateRequest • Custom Errors • Query String • Authentication Mechanism – Choose the Right One • Validations – Client Side, Server Side

• Design up front with performance in mind – Have performance plan in the very beginning • Don’t “add performance” as a post step! – Much harder to-do once a project written • Measure & iterate throughout project – Performance isn’t a one-time step – Iterative investigation is the approach to take – Always know the status of your performance

• Write clean/organized code – Don’t ‘hack’ solutions (keep code simple) – Easier to optimize – Easier to maintain • Follow good design practices: – Data Access – Server Controls – Output Caching

• ADO.NET has built-in connection pooling – Automatic caching/re-use of connections – No need to write any code for this to happen • Code Recommendation: – “Open connections in your code late, and then close them early” – Don’t hold on to connections for long periods of time – do not try to build your own “smart” connection pool logic – Close the connection as soon as you are finished with it (this returns it to the pool)

• Always explicitly close data connections – Otherwise connection will remain open until the next Garbage Collection – Leaking connections slows perf dramatically • Specifically watch for leaks during stress: – Monitor user connection count on database – Watch the .NET CLR Data Perf Counters – Look for steady state behavior (growing = bad)

• Optimization Tip: – Different connection strings can generate multiple different connection pools – Store single connection string in Web.Config – Using ConfigurationManager.ConnectionStrings to access it programmatically at runtime

• DataReader provides forward only data cursor over a query resultset – Lightweight and fast – but connection stays in use until Reader closed or finished • DataSet provides disconnected data access collection for data manipulation – Internally uses a DataReader to populate • Which is better? – Depends on size of data returned, and confidence that devs will close DataReader

• Only return data you need from the database – Memory allocations increase the more you return • SqlCommand.ExecuteScalar method – Tuned for scenarios where only a single value is returned for database • SqlCommand.ExecuteNonQuery – Tuned for scenarios where resultsets are not returned (except as params)

• Provides a clean programming abstraction – Recommended way to build ASP.NET pages – Makes profiling your code a lot easier • Controls do more work than old-style <%= %> – Should understand and optimize this • Two areas to review for optimization: – ViewState – Number of controls generated (especially for lists)

• ASP.NET controls can maintain state across round trips – State stored within “viewstate” hidden field • Some downsides: – Increases network payload (both on render and postback) – Performance overhead to serialize values to/from viewstate – Additional Per-Request Memory Allocation • Viewstate Flexibility: – Can disable viewstate entirely for a page – Can disable viewstate usage on a per control basis – Can use <%@ Page Trace=“true” %> to track usage size • Recommendations: – Always disable at page if you are not doing postback on a page – Disable on a control if you are always re-generating it on postback

• If you want to be more explicit about usage of viewstate, you can configure ASP.NET to turn it off by default • Machine.config: <configuration> <system.web> <pages enableViewState=“false”/> </system.web> </configuration> • Pages that need viewstate will then need to manually set it in page directive: – <%@ Page EnableViewState=“true” %>

• Leverage the built-in ASP.NET caching features – Output Caching – Partial Page Caching – Cache API • Recommendation: – Specifically design pages around these features – can lead to massive perf wins

Dynamic Static Static Dynamic

demo Output Caching

• Trace Tools • Profiler Tools • Load Tools

• ASP.NET Page or Application Tracing Display trace information on page • System.Diagnostics Tracing Write trace information to custom listener

• Request page 1050 times • Discard first 50 requests • Log time of each request • Average results

Four Database Tables • Products10 – 10 Rows • Products50 – 50 Rows • Products100 – 100 Rows • Products500 – 500 Rows

• DataReader • DataSet DisplayDataReader.aspx DisplayDataSet.aspx

4.0000 3.5585 3.5000 3.0000 2.5000 Milliseconds 2.0000 1.4234 1.5000 1.1982 0.9612 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx

4.5000 4.2160 4.0000 3.5000 3.0000 Milliseconds 2.5000 2.0000 1.6516 1.5000 1.3436 1.0979 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataSet.aspx

4.5000 4.2160 4.0000 3.5585 3.5000 3.0000 Milliseconds 2.5000 2.0000 1.6516 1.4234 1.5000 1.3436 1.1982 1.0979 0.9612 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx DisplayDataSet.aspx

Final Results On average, a DataReader is 16% faster than DataSet

Using an ArrayList instead of a DataReader results in similar performance with the advantages of a static representation of data DisplayArrayList.aspx

4.5000 4.2160 4.0000 3.6802 3.5585 3.5000 3.0000 Milliseconds 2.5000 2.0000 1.6516 1.4450 1.4234 1.5000 1.3436 1.1982 1.1925 1.0979 0.9717 0.9612 1.0000 0.5000 0.0000 1 2 3 4 DisplayDataReader.aspx DisplayDataSet.aspx DisplayArrayList.aspx

• SqlDataReader • OleDbDataReader

10.0000 9.0000 8.6055 8.0000 7.0000 6.0000 Milliseconds 5.0000 4.0000 3.5585 2.8741 3.0000 2.2088 2.0000 1.6592 1.4234 1.1982 0.9612 1.0000 0.0000 1 2 3 4 DisplayDataReader.aspx DisplayDataReaderOleDb.aspx

Final Results On average, a SqlDataReader is 115% faster than an OleDbDataReader

• Inline SQL • Stored Procedure

4.0000 3.5966 3.5585 3.5000 3.0000 2.5000 Milliseconds 2.0000 1.4234 1.4217 1.5000 1.1982 1.1648 0.9612 0.9458 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx DisplayDataReaderStoredProc.aspx

DataReader Column Reference • By Name: Response.Write(dr[“ProductName”]); • By Ordinal: Response.Write(dr[0]); • By GetString(): Response.Write(dr.GetString(0));

4.5000 4.0562 4.0000 3.5585 3.5000 3.0171 3.0000 Milliseconds 2.5000 2.0000 1.5029 1.4234 1.5000 1.3194 1.2306 1.1982 1.1209 0.9612 0.9485 0.9732 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx DisplayColumnOrdinal.aspx DisplayColumnNative.aspx

Final Results On average, ordinal reference is 11% faster than by name

• Proper Case dr[“ProductName”] • Improper Case dr[“PRODUCTNAME”]

4.0000 3.6232 3.5585 3.5000 3.0000 2.5000 Milliseconds 2.0000 1.4428 1.4234 1.5000 1.1982 1.2007 0.9753 0.9612 1.0000 0.5000 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx DisplayDataReaderBadCase.aspx

Final Results Using proper column case is 1% faster than improper column case

• Inline • ASP.NET Controls

18.0000 15.9660 16.0000 14.0000 12.0000 Milliseconds 10.0000 8.0000 6.0000 4.0302 3.8963 3.5585 4.0000 2.5259 1.4234 1.5173 2.0000 1.4247 1.1982 1.2337 0.9612 0.9652 0.0000 10 Row s 50 Row s 100 Row s 500 Row s DisplayDataReader.aspx DisplayDataReaderHTML.aspx DisplayDataGrid.aspx

Final Results • Inline script is 233% faster than a DataGrid

• DataGrid with ViewState Disabled • DataGrid with ViewState Enabled

35.0000 30.0000 28.8384 25.0000 Milliseconds 20.0000 15.9660 15.0000 10.0000 5.5437 5.0000 3.8963 3.4100 2.5259 1.7315 1.4247 0.0000 1 2 3 4 DisplayDataGrid.aspx DisplayDataGridViewState.aspx

Final Results DataGrid with ViewState disabled is 66% faster than DataGrid with ViewState enabled

• AutoGenerateColumns • Template Columns

25.0000 23.3265 20.0000 15.9660 15.0000 Milliseconds 10.0000 5.1431 5.0000 3.8963 3.1174 2.5259 1.5350 1.4247 0.0000 1 2 3 4 DisplayDataGrid.aspx DisplayDataGridTemplate.aspx

Final Results A DataGrid without templates is 39% faster than a DataGrid with templates

How to improve template performance? • DataBinder.Eval <%# DataBinder.Eval(Container.DataItem, “ProductName”) %> • Explicit Cast <%# ((DbDataRecord)Container.DataItem)[\"ProductName\"]%> • ItemDataBound void ItemDataBound(Object s, DataGridItemEventArgs e) DisplayItemDataBound.aspx

30.0000 27.7291 25.0000 23.3265 20.7450 20.0000 Milliseconds 15.0000 10.0000 5.9879 5.1431 4.6660 5.0000 3.1174 3.5255 2.8716 1.5350 1.6122 1.4977 0.0000 1 2 3 4 DisplayDataGridTemplate.aspx DisplayItemDataBound.aspx DisplayDataGridTemplateCast.aspx

Final Results Explicit cast is 11% faster than using a databinding expression

Would a custom DataGrid (with severely reduced functionality) be faster than the standard DataGrid? FastGrid.cs

25.0000 23.3265 20.0000 16.4522 15.0000 Milliseconds 10.0000 5.1431 5.0000 3.8371 3.1174 2.4726 1.5350 1.4329 0.0000 1 2 3 4 DisplayDataGridTemplate.aspx DisplayFastGrid.aspx

Final Results FastGrid is 37% faster than a standard DataGrid

• DataGrid with no caching • DataGrid with data caching • DataGrid with output caching

18.0000 15.9660 16.0000 14.0000 12.0000 Milliseconds 10.0000 8.0000 6.0000 3.8963 4.0000 2.5259 2.0000 1.4247 0.8336 0.7974 0.7985 0.8009 0.0000 1 2 3 4 DisplayDataGrid.aspx DisplayDataGridCache.aspx

Final Results Using the data cache is 637% faster than a standard DataGrid

18.0000 15.9660 16.0000 14.0000 12.0000 Milliseconds 10.0000 8.0000 6.0000 3.8963 4.0000 2.5259 2.0000 1.4247 0.8336 0.7974 0.7985 0.8009 0.0000 0.0000 0.0000 0.0000 0.0000 1 2 3 4 DisplayDataGrid.aspx DisplayDataGridCache.aspx DisplayDataGridOutputCache.aspx

Final Results Using the output cache is infinitely faster than using a standard DataGrid

• A DataReader is faster than a DataSet • An inline DataReader is faster than a DataGrid • You pay a high price for ViewState • AutoGenerateColumns is faster than template columns • Caching is always a good idea!

• Default Deployment Model copies both ASPX and Source files • Both Compiled Dynamically on first request • Precompiled Applications can be better in performance • Web Site Publishing Wizard pre-compiles the Source Files • ASPNET Compiler Tool Pre-compile both ASPX & Source

demo Deployment Tips

http://geekswithblogs.net/ranganh

ASP.NET Best Practices

0 comments

Notes on slide 1

Favorites, Groups & Events