Profiling and Optimizing 'NET Applications

1
Profiling and Optimizing.NET Applications

• Ingo Rammer
• http//www.thinktecture.com

2
Ingo Rammer and

• Support and consulting for software architects
  and developers
• Application Optimization and Tuning
• Developer-Coaching and -Mentoring
• Architecture and Code Reviews
• Prototyping and Architectural Consulting
• http//www.thinktecture.com
• ingo.rammer_at_thinktecture.com

3
Scenario I
ü Architecture ü Design ü Initial Coding and
Load Testing
4
Load Testing Pitfalls

• Its important to test the right thing
• Double-check that network link and client CPUs
  are not overloaded
• Run test clients in the same LAN as the servers
• Two ways of testing with very different results
• Simulated user load (including think times, etc.)
• Maximum Request Load (no think time, just load)
• Include ramp-up time (step user load)

5
Load Testing in Practice

• Track counters of multiple servers
• Test clients, Web servers, DB servers
• Liebigs Law of the Minimum is applicable here as
  well
• The scarcest resource will limit growth
• After the resource is identified, take action

6
Scenario II
ü Architecture ü Design ü Coding ü Test ü
Deployment
7

• Users

8
(No Transcript)
9
(No Transcript)
10

• Dont assume anything

11
1st - Trace the Network Interactions

• The wire never lies
• Wireshark/Ethereal (Sniffing)
• TcpTrace (Explicit Port-Forwarding)
• Fiddler, ProxyTrace (HTTP Proxies)
• Caution Some companies do not allow sniffing!

12
Things you might find out

• Overhead you didnt expect
• Authentication, sub-optimal bindings,
• Roundtrips you didnt expect
• Cookies
• Images (check your IE settings!)
• MarshalByRefObject-roundtrips
• General Too many roundtrips, or too big
• Latency vs. Bandwidth

13
2nd - Trace your SQL

• Most SQL today is generated
• DataSets and Adapters
• O/R Mappers
• Suboptimal SQL main reason for scalability probs
• Today's databases are (unfortunately?) very good
• Hide a lot of problems in single-user access
  during DEV

14
Invoicing Application Subset
InvoiceItems InvoiceId Itemld ProductId ProductNa
me Quantity Price Status
Invoice InvoiceId InvoiceDate CustomerId Status
SerialNumbers InvoiceID ItemId SerialNumber Statu
s
SerialNumberAudit AuditId EntryDate Username Seri
alNumber Description
15
Invoicing - Requirements

• Cancel (Status2)
• Copy

16
Lessons Learned from SQL Profiling

• DataSets, DataAdapters and O/R Mappers are great
  tools
• Can simplify more than 80 - 90 of your generic
  database access code
• BUT Please avoid them in high-load /
  high-throughput parts of your application

17
Optimize Your SQL for Transactions

• UPDATE with Foreign Keys
• INSERT INTO ... SELECT
• In the high-load areas of your application. Not
  everywhere!

18
Database Locks

• Minimize duration and number of locks
• Dynamic SQL (with parameters) vs. Stored
  Procedures
• UPDATE only changed rows if possible
• SELECT only the rows you need, join only tables
  you need
• Possibility changed isolation level (snapshot
  isolation or NOLOCK) in statistics if you have to
  report from OLTP data
• Dont use Sequence-Tables (better go for
  Autoincrement/Identity/Guid columns!)

19
The 1 Reason for Deadlocks
20
Indexes help a bit...

• Use Index (TableName)
• Not Index (TableName, NextValue)
• SQL Server An index is only locked when one or
  more of the contained fields are locked!
• Even snapshot isolation wont help you here
• Please note Oracle sequences behave differently.
  They always run without transaction locks.

21
3rd - Memory Profiling

• CLR Profiler 2.0 (free tool)
• Shows how much memory each method allocates
• Not leaks, just allocations

22
Memory Usage

• Important for multi-user applications
• Issue Multiple GC-cycles during one request
• Generative GC
• Short-lived objects end up in generation 2
• You can quickly check this in PerfMon, too!
• .NET CLR Memory/Gen 0 Collections, 1, 2
• 2,5 GB practical maximum for ASP.NET apps on 32
  bit systems

23
In-Process Profiling

• Often as a last step
• Reason In-Proc affects only performance
• Reason 2 After eliminating memory hogs, code
  will usually be faster anyway
• Profiler
• Jetbrains DotTrace
• Redgate ANTS
• Automated QA AQTime
• Compuware DevPartner

24

• I code well, so wheres the scary part?

25
The Scary Facts

• SqlDataSource
• Grid A 23,926,450 Bytes
• Grid B 17,147,255 Bytes
• Grid C 3,325,839 Bytes
• GridView 2,583,207 Bytes
• ObjectDataSource
• GridView 169,551 Bytes
• Grid C 916,769 Bytes
• Manual
• HTML Tables 51,237 Bytes
• w/o ViewState 43,897 Bytes

26
Summary

• Dont assume anything
• Network the wire never lies (auth overhead,
  roundtrips, )
• Database generated SQL
• Memory multiple GCs for one request?
• In-Proc Performance as the last step (scale up)
• Dont trust anyone
• It might not be your code, but it could be your
  job!

27
(No Transcript)
28
Resources

• Wireshark/Ethereal http//www.wireshark.com
• Fiddler http//www.fiddlertool.com
• TcpTrace, ProxyTrace http//www.pocketsoap.com
• SQL Profiler out of the box
• CLR Profiler 2.0 cryptic link, please google

29
(No Transcript)
30
2006

• DSL, WLAN, MBits,
• Ping to New York 800 msec
• Download of 3,6 GB (Visual Studio)
• 6 Hours

31
Early 90s

• 1200 baud acoustic coupler
• Ping to New York 1200 msec
• Download of 3,6 GB (Visual Studio)
• 347 Days

32
Early 90s
Download 347 Days
Walking 20.000 km 5 km per hour 12 hours per day
? 333 Days
33
2006

• Latency (Ping) 33 improvement
• Bandwidth 138 800 improvement