JPDM, A Structured approach To Performance Tuning. Copyright 2017 Kirk Pepperdine. All rights reserved

Transcription

1 JPDM, A Structured approach To Performance Tuning

2 About Us Performance Consulting Java Performance Tuning Workshops Co-Founded jclarity

3 Disclaimer

4 Our Typical Customer Application isn t performing to project sponsors expectations users wait for minutes for the application to respond

5 Our Typical Customer Application isn t performing to project sponsors expectations users wait for minutes for the application to respond

6 Developers Get Involved StringBuffer is being used all over the place We need to change it to StringBuilder Looks like a database problem, we need to migrate to [buzzname goes here]

7 where is the problem?

8 Managers Get Involved Form a tiger team

9 What is a Tiger Team? A team of specialists in a particular field brought together to work on specific tasks.

10 What is a Tiger Team? A forum where experts from different disciplines come together to express an opinion that defends their specialty

11 Measure Don t Guess!!! Solid measures can help focus teams

12 What is JPDM A Java Performance Diagnostic Model

13 Why a System Model? Help us to understand what measures are important defines requirements for tooling provides a context for us to understand the measures facilitate the definition of a diagnostic process Java Performance Diagnostic Model (JPDM)

14 Where do Developers Live?

15 Developers Work Here Application Code (algorithms)

16 Developers Work Here Application Code (algorithms) JVM Managed Memory, Execution Engine Work in a virtualized environment

17 Application public class Software { public static void main( String[] args) { System.out.println( Software is abstract ); } } Code (algorithms) JVM Managed Memory, Execution Engine

18 Hardware is Real! capacities volume throughput clock speed granularity cache line, sector size

19 CPU capacity : number of cores number of units in ALU size of caches throughput : clock speed, CPI bandwidth on various pipes (QPI) granularity : cache line size

20 Memory capacity : number of bytes of RAM throughput : clock speed of BUS tempered by bank cool of time chunk size : cache line size typically 8 reads per cache line

21 Disk capacity : number of bytes of RAM throughput : controller clock speed ~1 Bbit/sec (SATA ~3Gbits/sec) granularity : disk sector (512 bytes) other latencies sweep arm speed

22 Network capacity : 1 per network card bandwidth : maximum volume of data transferred per second (10^9 bits/sec) throughput : depends on protocol overheads granularity : depends on protocol tcp payload is typically 1500 bytes

23 Other Limits Other hardware devices eg, video, sound cards GPU Heat Battery capacities

24 Performance picture emerges when Application Abstraction Code (algorithms) JVM meets Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks Reality

25 Application Code (algorithms) JVM No Dynamics Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks

26 Actors usage patterns Application Add dynamics Code (algorithms) JVM Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks

27 Which is faster? a) Bubble sort b) Quick sort Question?

28 Hint In Big O notation... - Bubble sort is N^2 - Quick sort of Nlog(N)

29 However quick bubble

30 However quick bubble Number of items comes from the actors

31 Performance Tuning Methodology Based on the System model we just developed hypothesis free methodical step wise process to arrive at a conclusion If youombine

32 Hardware Consumption Actors usage patterns Application Code (algorithms) JVM Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks Actors drive the application Application drives the JVM function of how actors interact with application JVM assisted by OS consumes Hardware function of how application is coded Hardware is consumed consumption limited by capacity pattern of consumption is important

33 Dominating Consumer Actors usage patterns Application Code (algorithms) JVM Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks Activity that dominates how the CPU is utilized Determination dominator by analyzing CPU counters Garbage collection logs garbage collection logs

34 Dominating Consumers Actors usage patterns Application Code (algorithms) JVM Managed Memory, Execution Engine OS/Hardware CPU, memory, disk I/O network I/O, Locks Application JVM System None

35 sys cpu > ~10% of user cpu yes Analysis System no system profiling: netstat, mpstat, iostat, sar, strace, etc... user CPU ~= 100% yes memory efficient? GC Logs yes Application no no None JVM app/cpu profiling Thread starvation Thread dump GC tuning, pool sizes, collectors,... Memory profiling, size frequency, life span,...

36 Expression of CPU Consumption System None passively dominant JVM aggressivly dominant Application

37 Measuring Consumption System Kernel time Application Idle User time None JVM

38 r b swpd free buff cache si so bi bo in cs us sy id wa

39 Benchmarking Process Benchmark benchmark = new Benchmark() benchmark.configure(); performance = benchmark.baseline(application); user.sethappy(performance.meets(requirements)); while ((! user.ishappy()) && (user.hasmoney())) { Profiler profiler = performance.identifydominatingconsumer(); profilingresults = benchmark.profile(profiler); application.fixusing( profilingresults); while ( application.failsqa()) application.debug(); performance = benchmark.baseline(application); user.sethappy(performance.meets(requirements)); }

40 Things We Need Actors Test harness Application Data Monitoring JVM Hardware/OS

41 Time for a demo

42 Questions?