Alois Reitbauer on Performance Forensics

Transcript

1. Performance Forensics Alois Reitbauer dynaTrace Software
2. Forensics forensis adj - "of or before the forum." In Roman tmes, a criminal charge meant presentng the case before a group of public individuals in the forum. … The individual with the best argument and delivery would determine the outcome of the case.
3. Collecting Evidence
4. What does this chart tell us Time Response Time
5. A- Response time problem? B - CPU problem? C - Sync problem? D - Database problem?
6. We don‘t know
7. We have to collect our evidence first
8. System/OS/Virtualization-Level Container/App Server-Level Application-Level User-Level Multi-Layered Measurement
9. Understand your measurements Response Time only Response Time and GC
10. A: Our response time is 2.3 seconds B: Our response time is 1.5 seconds C: Our response time is 6 seconds How can this happen?
11. Browser Firewall Network Sniffer Web Server Application Server  Page Load Time  HTTP Request Time Request Time (max) 95 % Servlet Time The beauty of measures ... ... is that there are so many to choose from
12. Types of Measurements Cyclic Measurements Are collected ar regular time intervals Are time based JMX, CPU, Memory Event-based measurements Are collected as a request occurs Are transactional Response Times, CPU consumption
13. Types of Statistics Min/Max Average Median Percentiles Use percentiles for event-based measures and averages (or max) for cyclical measures
14. How you measure is important
15. Typical Measurements we work with Memory Consumption, GC CPU Usage, Load Average Response Time Transactions Database Statements, Pool Sizes Communication Calls, Latency, Size, Threads
16. A Clearer Picture
17. What is the problem? We have response times of 6 seconds. We have response times of 6 seconds for 95 percent of our users at a load of 500 users with a CPU utilization of 10 percent.
18. Indentify the suspect
19. Don‘t trust your assumptions
20. Top 10 Optimizations are bad
21. Seperate transaction types
22. Baseline and Delta
23. Understand the difference
24. Make the problem reproducable. Otherwise you cannot check whether you fixed it.
25. When are we done?
26. ... when there are no more why questions
27. Solving the case
28. Ensure you solved the real problem
29. Fight problems not symptoms
30. When a measure supports a problem. Check for all measures affected by the problem.
31. Have you tuned at the right place
32. Watch out for side effects
33. The usual suspects
34. O/R Access Rendering State Handling Latency Data Volume Comm. Behavior JavaScript Database Business Tier Browser Web Tier Data Volume Number of Requests Memory and GC Memory and GC
35. Clie nt A pplication Stub Se rialization Clie nt Infrastructure Se rve r A pplication Facade De se rialisation Se rve r Infrastructure Ne tworking Ne tworking A pplication Deve lope rs View Remoting Stack
37. Avoid Protocol Overhead Reduce Interactions Create Data Locality Adjust Interfaces
38. Application Code Connection Pool Connection Result Set Application SQL TCP/IP Database O/R Mapping Layer Caching Layer Statement Connection Prepared Statement Prepared Statement . . . The DB layer
39. Persistence Framework JDBC Layer Database Execution Plan Cache Prepared Statement Cache Cross Session Cache Session Caches Query Cache(s) Caching in the DB layer
40. Reduce DB Calls Tune Loading Behavior Optimize for caching Define Proper Entities select … from a,b,c select … from b,c,a … join fetch ….
41. The Web Layer
42. Browse r Se rve r JavaScript Pe rform ance H TM L Re nde ring M any A JA X /H TTP calls H ig h Late ncy H ig h Datavolum e Thre ad -/ Conne ctionpools Ne twork Datab ase A cce ss We b Se rvice / Backe nd Calls B rowse r B rowse r
43. Caching on the Web Clie nts Se rve r Cache pe r Clie nt Se rve r provid ing Caching Inform ation Prox y Cache for M any Clie nts Se rve rsid e Data Cache
44. Alois Reitbauer alois.reitbauer@dynatrace.com @AloisReitbauer blog.dynatrace.com