ASP.NET Best Practices
•Download as PPTX, PDF•
1 like•1,319 views
The document provides guidance on optimizing web application performance in ASP.NET. It discusses strategies like designing for performance upfront, measuring and iterating throughout development, writing clean code, leveraging caching, optimizing data access with techniques like using a SqlDataReader over a DataSet, and reducing viewstate. It also shares results of performance tests comparing different data access methods and controls. The overall message is that performance should be considered throughout the development process through best practices and targeted optimizations.
More Related Content
Similar to ASP.NET Best Practices
Similar to ASP.NET Best Practices (20)
More from Harish Ranganathan
More from Harish Ranganathan (14)
Recently uploaded
Recently uploaded (20)
ASP.NET Best Practices
- 1. Harish Ranganathan Web Developer Evangelist Microsoft Corporation India
- 2. • Web Application Security – Quick Tips • Performance Overview • Performance Improvements in .NET 2. • Performance when developing • Performance when deploying • Results of a Few Performance Tests
- 3. • ValidateRequest • Custom Errors • Query String • Authentication Mechanism – Choose the Right One • Validations – Client Side, Server Side
- 5. • 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
- 7. • 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
- 9. • 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)
- 10. • 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)
- 11. • 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
- 12. • 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
- 13. • 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)
- 15. • 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)
- 16. • 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
- 17. • 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” %>
- 19. • 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
- 20. Dynamic Static Static Dynamic
- 21. demo Output Caching
- 22. • Trace Tools • Profiler Tools • Load Tools
- 23. • ASP.NET Page or Application Tracing Display trace information on page • System.Diagnostics Tracing Write trace information to custom listener
- 24. • Request page 1050 times • Discard first 50 requests • Log time of each request • Average results
- 25. Four Database Tables • Products10 – 10 Rows • Products50 – 50 Rows • Products100 – 100 Rows • Products500 – 500 Rows
- 26. • DataReader • DataSet DisplayDataReader.aspx DisplayDataSet.aspx
- 27. 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
- 28. 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
- 29. 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
- 30. Final Results On average, a DataReader is 16% faster than DataSet
- 31. Using an ArrayList instead of a DataReader results in similar performance with the advantages of a static representation of data DisplayArrayList.aspx
- 32. 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
- 34. 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
- 35. Final Results On average, a SqlDataReader is 115% faster than an OleDbDataReader
- 36. • Inline SQL • Stored Procedure
- 37. 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
- 38. DataReader Column Reference • By Name: Response.Write(dr[“ProductName”]); • By Ordinal: Response.Write(dr[0]); • By GetString(): Response.Write(dr.GetString(0));
- 39. 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
- 40. Final Results On average, ordinal reference is 11% faster than by name
- 41. • Proper Case dr[“ProductName”] • Improper Case dr[“PRODUCTNAME”]
- 42. 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
- 43. Final Results Using proper column case is 1% faster than improper column case
- 44. • Inline • ASP.NET Controls
- 45. 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
- 46. Final Results • Inline script is 233% faster than a DataGrid
- 47. • DataGrid with ViewState Disabled • DataGrid with ViewState Enabled
- 48. 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
- 49. Final Results DataGrid with ViewState disabled is 66% faster than DataGrid with ViewState enabled
- 50. • AutoGenerateColumns • Template Columns
- 51. 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
- 52. Final Results A DataGrid without templates is 39% faster than a DataGrid with templates
- 53. How to improve template performance? • DataBinder.Eval <%# DataBinder.Eval(Container.DataItem, “ProductName”) %> • Explicit Cast <%# ((DbDataRecord)Container.DataItem)[quot;ProductNamequot;]%> • ItemDataBound void ItemDataBound(Object s, DataGridItemEventArgs e) DisplayItemDataBound.aspx
- 54. 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
- 55. Final Results Explicit cast is 11% faster than using a databinding expression
- 56. Would a custom DataGrid (with severely reduced functionality) be faster than the standard DataGrid? FastGrid.cs
- 57. 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
- 58. Final Results FastGrid is 37% faster than a standard DataGrid
- 59. • DataGrid with no caching • DataGrid with data caching • DataGrid with output caching
- 60. 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
- 61. Final Results Using the data cache is 637% faster than a standard DataGrid
- 62. 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
- 63. Final Results Using the output cache is infinitely faster than using a standard DataGrid
- 64. • 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!
- 65. • 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
- 66. demo Deployment Tips
- 69. © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.