DEV302

Best Practices and Techniques for Web Performance

Scott Guthrie

ASP.NET Team

Agenda

Performance OverviewHow to think about web performance

Tools of the TradeHow to Measure/Analyze Performance

ASP.NET Performance Best PracticesSpecific recommendations on techniques to optimize ASP.NET web performance

Slides and code posted at:

http://www.scottgu.com

Performance Overview

Performance Is A Feature

Design up front with performance in mindHave 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 projectPerformance isn’t a one-time step

Iterative investigation is the approach to take

Quantifying web performance

Client Response TimeDefinition: How “fast” does web application appear to remote browser hitting the siteMeasured via TTFB (time to first byte)Measured via TTLB (time to last byte)Impacts customer satisfaction with app

Machine ThroughputDefinition: How many client requests can a server handle under loadMeasured in # of requests/secImpacts # of servers you need to buy

Tools of the Trade

Measuring Web Performance

Only way to measure web server performance is by stress testing the server

Automated stress tools only way to measure

Hitting refresh in the browser doesn’t count…

Collect performance data on multiple scenarios:Simulate end to end scenario walkthrough of app

Measure individual page performance (hotspots)

Performance metrics to measure:Request/sec using different client loads

Identify maximum client load that fits into acceptable TTFB/TTLB response time range

Performance Test Tools

Microsoft Web Application Stress ToolFree 10Mb download for XP, 2000, 2003

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/intranet/downloads/webstres.asp

Microsoft Application Center Test ToolShips as part of VS.NET Enterprise

Enables richer scripting and reporting

Key PerfMon CountersProcessor, CPU % Utilization

Low numbers = blocking or lock contention

ASP.NET Applications, Requests/SecDynamic throughput (should be consistent)

ASP.NET, Requests In Application QueueLinear growth here indicates server maxed

ASP.NET Application, Errors TotalIndicates functional problems (should be 0)

ASP.NET App/Worker Process Restarts

Indicates serious functional problems

Performance Tool Notes

Always run stress tools on separate machine from web server

Otherwise tool will max out server CPU

Use multiple client machines for heavy load

Configure tests to simulate different client bandwidth levels

Specifically measure 56k dialup

Using free Microsoft Web Using free Microsoft Web Application Stress ToolApplication Stress Tool

demodemo

ASP.NET Performance Best Practice Recommendations

Best Practices

Write clean/organized codeDon’t ‘hack’ solutions (keep code simple)

Easier to optimize

Easier to maintain

Follow good design practices:Logical/Physical Design

Language/Code Choices

Data Access

Server Controls

Output Caching

Logical/Physical Design Recommendations

Logical Design

Recommendation: Use logical 3-tier modelPages (.aspx) and User Controls (.ascx) UI

Business and Data Access classes in \bin dir

Data within a SQL Database via SPROCs

Physical DeploymentRecommendation: Stay in the same process

Things to avoid (when possible *):Remote object invocation via DCOM

Synchronous calls to XML Web Services

Use XML Web services for:Application to application communication

Do not use for intra-application communication

** Application requirements sometimes dictate physical separation Application requirements sometimes dictate physical separation of machines – the point is to not do this unnecessarily without of machines – the point is to not do this unnecessarily without very compelling reasons (and be aware perf will suffer) very compelling reasons (and be aware perf will suffer)

Physical Deployment for Security

Recommendation: Use ISA Server

Security zone requirementRestrict access only to ISA

ISA tunnels through DMZ to ASP.NET

Eliminates process-boundary hops

BrowsersBrowsers SQLSQLISAISA

DMZ (firewall)DMZ (firewall)ASP.NETASP.NET

Application Application LogicLogic

DMZ Performance Benchmark

Test Scenario:Physical multi-machine deployment

Design Goal: Application server not accessible

2 Techniques Measured:ASP.NET using remoting to access logic

ISA front-end hitting ASP.NET server that contains both pages and the application business logic

3 Tier Deployment Numbers

0

200

400

600

800

1000

1200

1400

Remoting 3-Tier ISA 3-Tier

Req

ues

t/S

ec

Language/Code Recommendations

Code Performance

Common Language Runtime (CLR)Big runtime performance wins

JIT compilation to native code at runtime

Server optimized memory garbage collector

Trivia: Which is faster -- code behind or inline?No performance difference

Trivia: Which is faster -- VB .NET or C#?No measurable difference, however…

Language ChoiceEquivalent code provides equivalent performance

…but, you can produce different code:

‘ ‘ VB Late Binding ExampleVB Late Binding ExampleDim CountDim CountFor Count = 0 to 7For Count = 0 to 7 Response.Write(“Count: “ & Count) Response.Write(“Count: “ & Count)Next CountNext Count

‘ ‘ VB Early Binding ExampleVB Early Binding ExampleDim Count as IntegerDim Count as IntegerFor Count = 0 to 7For Count = 0 to 7 Response.Write(“Count: “ & Count) Response.Write(“Count: “ & Count)Next CountNext Count

Language Recommendations

Recommendation: Avoid late binding

In VB and JScriptExplicitly declare all variable types (Dim x as String)

Avoid late bound methods on Object type

<%@ Page Language=“VB” Explicit=“true” %>Requires all variables to be declared (Dim required)

Still enables late bound code to exist though

<%@ Page Language=“VB” Strict=“true” %>Disallows any late bound code to be used

Data Recommendations

Use the Right Data Provider

ADO.NET supports multiple providers:System.Data.SqlClient

System.Data.OracleClient

System.Data.OleDb

System.Data.Odbc

Programming model same across providersBut performance differences definitely exist

Recommendation: Use the appropriate providerAlways use SqlClient when accessing MSDE/SQL

Always use OracleClient when accessing Oracle

Data Provider Test

Scenario:50 Rows From SQL Northwinds Database

<%= %> html table formatting technique

Different data providers (ADO and ADO.NET)

Three Techniques Measured:Classic ASP/ADO

ASP.NET w/ System.Data.OleDb Provider

ASP.NET w/ System.Data.SqlClient Provider

0

100

200

300

400

500

600

700

800

900

Classic ASP/ ADO ASP.NET w/ OLEDB ASP.NET w/ SQL

Req

ues

t/S

ec (

4P S

erve

r)

Data Performance Test

Connection Pooling

ADO.NET has built-in connection poolingAutomatic caching/re-use of connectionsNo 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 logicClose the connection as soon as you are finished with it (this returns it to the pool)

Watch for Connection Leaks

Always explicitly close data connectionsOtherwise connection will remain open until the next Garbage CollectionLeaking connections slows perf dramatically

Specifically watch for leaks during stress:Monitor user connection count on SQL ServerWatch the .NET CLR Data Perf CountersLook for steady state behavior (growing = bad)

Tip: Database server connections count should roughly correspond to ASP.NET Pipeline Instance Count

Connection Pooling

Optimization Tip: Different connection strings can generate multiple different connection pools

Store single connection string in Web.Config

Using ConfigurationSettings.AppSettings to access it programmatically at runtime

Watch the “.NET CLR Data” Perf Counters to keep track of the number of connection pools maintained by ADO.NET

DataReaders vs. DataSets

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 your scenarios – if you do a lot of data manipulation, a DataSet is probably just as fast as building custom collection over DataReader

Use Stored Procedures

Recommend SPROCs for data accessEnable easier performance tuning by a DBA

Help eliminate database round trips

Avoid distributed tx costs by using DB transactions

Help prevent SQL Injection attacks (non perf win)

Performance Tip:Avoid naming sprocs: “sp_”, “fn_”, “sys”

Interesting Tip:Can turn off dynamic SQL support via Enterprise manager to enforce SPROC usage

Watch the Database

Carefully monitor your DB during stressTrack CPU performance of DB server

Track number of SQL user connections

Use SQL Profiler to analyze DB activityTrack queries accessed and execution time

Carefully review indexes based on access

Recommendation: Ken England’s: “Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook” (Digital Press)

Server Control Performance Recommendations

Server Controls

Provides a clean programming abstractionRecommended way to build ASP.NET pages

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)

ViewState ManagementASP.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

Viewstate Flexibility:Can disable viewstate entirely for a pageCan disable viewstate usage on a per control basisCan use <%@ Page Trace=“true” %> to track usage size

Recommendations:Always disable at page if you are not doing postback on a pageDisable on a control if you are always re-generating it on postback

Optimizing ViewState Optimizing ViewState using Tracingusing Tracing

demodemo

Viewstate Discussion

When does it make sense to use Viewstate versus recreating them on each request?

Depends on your scenario…

Bandwidth pipe to browser the key considerationViewstate needs to be small (<1k) for 56k dialup users

Viewstate size less important on fast pipe Intranets

Recommendation:Always be aware and track viewstate sizes, you can then make decisions based on scenario needs

Important: You do not need to use viewstate in order to leverage ASP.NET controls

View State Management TipIf 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” %>

Number of Controls GeneratedThere is a fixed cost to each server control used on a page

Cost usually negligible on per control basis

Composite controls can sometimes mask the number of controls used though

The aggregate cost can sometimes add up

Eg: <asp:datagrid> w/ 10 rows + 7 colsUses <asp:table> internally with 10 table row controls, each with 7 column controls70 controls now used to display the data20 more controls if “edit” button displayed

Data Listing Rendering Test

Scenario:50 Row Query from SQL Northwinds Database

Formatted into an html table

Five rendering techniques measured:Classic ASP <% %> w/ ADO

ASP.NET <% %> w/ ADO .NET

ASP.NET Repeater w/ ADO .NET

ASP.NET DataGrid w/ ADO .NET

0

100

200

300

400

500

600

700

800

900

Classic ASP ASP.NETDataGrid

ASP.NETRepeater EB

ASP.NET <%= %>

Req

ues

t/S

ec (

4P S

erve

r)

List Rendering Optimizations

In majority of scenarios the standard ASP.NET list/repeating controls provide more than enough performance

To optimize performance, you can also create your own custom server controls

Can be as fast as inline <%= %> within page

Best of both worlds: tweaked performance for your scenario with clean server control programming model

List Rendering List Rendering OptimizationsOptimizations

demodemo

Caching Performance Best Practices

Design For Caching

Leverage the built-in ASP.NET built-in caching features

Output Caching

Partial Page Caching

Cache API

Recommendation:Specifically design your pages around these features – can lead to massive perf wins

ASP.NET Caching

Cache APICache API

Partial PagePartial Page

Output CachingOutput Caching

Data CachingData Caching

PagePage Web ServiceWeb ServiceLow LevelLow Level

High LevelHigh Level

Output CachingCaches the static result of an ASP.NET page

Declarative <%@ OutputCache %> directiveOptional Output Cache APIs can also be called

Caching Options:Duration

Time item exists in the cacheVaryByParam

Varies cache entries by Get/Post paramsName param, separate by semi-colons, supports *

LocationCan save cache on the server, or push down to proxies

VaryByHeaderVaries cache entries by Http header

VaryByCustomOverride method within Global.asax to custom vary by whatever you want (you control the cache key)

Cache Performance CountersASP.NET Application, Output Cache Entries

Total # of items stored in output cache

ASP.NET Application, Output Cache HitsTotal # of items served from output cache

ASP.NET Application, Output Cache MissesTotal # of cacheable items not served from cache

Output CachingOutput Caching

demodemo

Kernel Caching in IIS6

ASP.NET leverages kernel cache on IIS6As fast as static html in these cases

Requirements for kernel cache promotion:HTTP GET Request (no posted pages)No VaryByParamNo VaryByHeaderNo security restrictions to page

Note: ASP.NET Request/Cache counters will not update when kernel hit occurs

Monitor “Web Service Cache” counter group

PagePage

Partial Page Caching

Web ServiceWeb Service

Output CachingOutput Caching

Cache APICache API

Partial PagePartial Page

Data CachingData Caching

StaticStaticD

ynam

icD

ynam

ic

Dyn

amic

Dyn

amic

StaticStatic

Partial Page Caching

Partial Page Caching allows caching page regions using user controls (.ascx)

User controls have <%@ OutputCache %> directive

Additional Features“VaryByControl”– Varies cached items by controls

“VaryByCustom” – Allows user cache key method

“Shared” – V1.1 attribute to share output cross pages

Recommendations: Look to use this feature very aggressively

If you don’t think you can use it, look again because you haven’t thought about it hard enough

Partial Page CachingPartial Page Caching

demodemo

Misc Perf Config Gotchas

Make sure debug is turned offWeb.config : <compilation debug=“false”/>VS.NET leaves on debug by default

Make sure tracing is turned offWeb.config and page directive

IIS 6.0 Process Model RestartsDefault restart is every 29 hours – turn off

IIS 6.0 Maximum Used MemorySet to 60% of physical memory (keep < 800mb)Important to set if output cache used aggressively

Summary

Building high performance web apps isn’t hard if you design for perf up front

Measure and iterate along the way

Always right clean, maintainable code“Clever” hacks don’t make you “smart”

Follow the recommendations in the slidesYou’ll have clean, fast ASP.NET solutions

Additional Resources

http://www.asp.net web siteBest resource for anything ASP.NETASP.NET Performance Forum

http://www.aspadvice.comExcellent email listserv

“Professional ASP.NET Performance” Book by Wrox Press

Suggested Reading And Resources

The tools you need to put technology to work!The tools you need to put technology to work!

TITLETITLE AvailableAvailable

Microsoft® ASP.NET Setup and Microsoft® ASP.NET Setup and Configuration Pocket Reference: Configuration Pocket Reference: 0-7356-1936-00-7356-1936-0

TodayToday

Performance Testing Performance Testing Microsoft® .NET Web Microsoft® .NET Web Applications: 0-7356-1538-1Applications: 0-7356-1538-1

TodayToday

Microsoft Press books are 20% off at the TechEd Bookstore

Also buy any TWO Microsoft Press books and get a FREE T-Shirt

evaluationsevaluations

© 2003 Microsoft Corporation. All rights reserved.© 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.