ASP.NET Best Practices

  • 2,079 views
Uploaded on

Presention on ASP.NET Security and Performance Tips and Tricks

Presention on ASP.NET Security and Performance Tips and Tricks

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,079
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
231
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 4. • 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
  • 5. • 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
  • 6. • 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)
  • 7. • 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)
  • 8. • 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
  • 9. • 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
  • 10. • 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)
  • 11. • 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)
  • 12. • 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
  • 13. • 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” %>
  • 14. • 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
  • 15. Dynamic Static Static Dynamic
  • 16. demo Output Caching
  • 17. • Trace Tools • Profiler Tools • Load Tools
  • 18. • ASP.NET Page or Application Tracing Display trace information on page • System.Diagnostics Tracing Write trace information to custom listener
  • 19. • Request page 1050 times • Discard first 50 requests • Log time of each request • Average results
  • 20. Four Database Tables • Products10 – 10 Rows • Products50 – 50 Rows • Products100 – 100 Rows • Products500 – 500 Rows
  • 21. • DataReader • DataSet DisplayDataReader.aspx DisplayDataSet.aspx
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Final Results On average, a DataReader is 16% faster than DataSet
  • 26. Using an ArrayList instead of a DataReader results in similar performance with the advantages of a static representation of data DisplayArrayList.aspx
  • 27. 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
  • 28. • SqlDataReader • OleDbDataReader
  • 29. 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
  • 30. Final Results On average, a SqlDataReader is 115% faster than an OleDbDataReader
  • 31. • Inline SQL • Stored Procedure
  • 32. 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
  • 33. DataReader Column Reference • By Name: Response.Write(dr[“ProductName”]); • By Ordinal: Response.Write(dr[0]); • By GetString(): Response.Write(dr.GetString(0));
  • 34. 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
  • 35. Final Results On average, ordinal reference is 11% faster than by name
  • 36. • Proper Case dr[“ProductName”] • Improper Case dr[“PRODUCTNAME”]
  • 37. 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
  • 38. Final Results Using proper column case is 1% faster than improper column case
  • 39. • Inline • ASP.NET Controls
  • 40. 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
  • 41. Final Results • Inline script is 233% faster than a DataGrid
  • 42. • DataGrid with ViewState Disabled • DataGrid with ViewState Enabled
  • 43. 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
  • 44. Final Results DataGrid with ViewState disabled is 66% faster than DataGrid with ViewState enabled
  • 45. • AutoGenerateColumns • Template Columns
  • 46. 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
  • 47. Final Results A DataGrid without templates is 39% faster than a DataGrid with templates
  • 48. 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
  • 49. 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
  • 50. Final Results Explicit cast is 11% faster than using a databinding expression
  • 51. Would a custom DataGrid (with severely reduced functionality) be faster than the standard DataGrid? FastGrid.cs
  • 52. 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
  • 53. Final Results FastGrid is 37% faster than a standard DataGrid
  • 54. • DataGrid with no caching • DataGrid with data caching • DataGrid with output caching
  • 55. 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
  • 56. Final Results Using the data cache is 637% faster than a standard DataGrid
  • 57. 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
  • 58. Final Results Using the output cache is infinitely faster than using a standard DataGrid
  • 59. • 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!
  • 60. • 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
  • 61. demo Deployment Tips
  • 62. http://geekswithblogs.net/ranganh
  • 63. © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.