Designing for Performance. Martin Thompson

Transcription

1 Designing for Performance Martin Thompson

2 Is it difficult writing software that has good performance?

3

4 RDD (Resume Driven Development)

5

6 How do we Design for Performance?

7 1. What is Performance? 2. What is Clean & Representative? 3. Implementing efficient Models 4. Why Performance Test?

8 Performance

9 Throughput (aka Bandwidth)

10 Response Time (aka Latency)

11 Scalability

12

13 Response Time Queuing Theory Utilisation

14 Pro Tip: Ensure you have sufficient capacity

15 Can we go parallel to speedup?

16 Amdahl s Law time Sequential Process A B

17 Amdahl s Law time Sequential Process A B Parallel Process A A A A A B

18 Amdahl s Law time Sequential Process A B Parallel Process A A A A A B Parallel Process B A B B B B

19 Amdahl s Law

20 Universal Scalability Law C(N) = N / (1 + α(n 1) + ((β* N) * (N 1))) C = capacity or throughput N = number of processors α = contention penalty β = coherence penalty

21 Speedup Universal Scalability Law Processors Amdahl USL

22 Time (nanoseconds) 160, , , ,000 80,000 60,000 40,000 20,

23 Time (nanoseconds) Mean Logging Duration 160, , , ,000 80,000 60,000 40,000 20,

24 Clean & Representative

25 - Clean Morally uncontaminated; pure; innocent - Oxford English Dictionary

26 - Representative Serving as a portrayal or symbol of something - Oxford English Dictionary

27 - Representative Code is the best place to capture our current understanding of a model

28 Abstractions

29 Rules of Abstraction 1. Don t use abstraction

30 Rules of Abstraction 1. Don t use abstraction 2. Don t use abstraction

31 Rules of Abstraction 1. Don t use abstraction 2. Don t use abstraction 3. Only consider abstracting when you see at least 3 things that ARE the same

32 Rules of Abstraction 1. Don t use abstraction 2. Don t use abstraction 3. Only consider abstracting when you see at least 3 things that ARE the same 4. Abstractions must pay for themselves

33 Rules of Abstraction 1. Don t use abstraction 2. Don t use abstraction 3. Only consider abstracting when you see at least 3 things that ARE the same 4. Abstractions must pay for themselves 5. Beware DRY, the evil siren that tricks you into abstraction -> Coupling

34 Abstraction Megamorphism => Branch Hell

35 Abstraction Not Representative => Big Smell

36 Abstraction Say no to big frameworks!

37

38 Pro Tip: Abstract when you are sure of the benefits

39 Law of Leaky Abstractions All non-trivial abstractions, to some extent, are leaky. - Joel Spolsky

40 Law of Leaky Abstractions The detail of underlying complexity cannot be ignored.

41 the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise - Dijkstra

42 Can we abstract memory systems?

43 - It s about 3 bets!

44 - It s about 3 bets! 1. The Temporal Bet

45 - It s about 3 bets! 1. The Temporal Bet 2. The Spatial Bet

46 - It s about 3 bets! 1. The Temporal Bet 2. The Spatial Bet 3. The Pattern Bet

47 Model Implementation

48 Coupling & Cohesion

49 Coupling & Cohesion Properties Bag

50 Pro Tip: Respect Locality of Reference

51 Can you implement a B+ Tree efficiently in a language?

52 Relationships

53 Relationships Order Book Order

54 Relationships Order Book 1 Bids * 1 Offers * Order

55 Relationships Order Book Price Price 1 Bids * 1 Offers * Order

56 Relationships Order Book Price Price 1 Bids * {ordered, FIFO} 1 Offers * {ordered, FIFO} Order

57 Pro Tip: Make friends with your Data Structures

58 Batching

59 Amortise the expensive costs

60 Natural Batching Producers

61 Natural Batching << Amortise Expensive Costs >> Batcher Producers

62 Response Time Natural Batching Typical Possible Load

63 Pro Tip: Batch processing is not just for offline

64 Branches, branches, branches...

65 Branches public void dostuff(list<string> things) { if (null == things things.isempty()) { return; } } for (String thing : things) { // Do useful work }

66 Branches public void dostuff(list<string> things) { if (null == things things.isempty()) { return; } } for (String thing : things) { // Do useful work }

67 Branches public void dostuff(list<string> things) { for (String thing : things) { // Do useful work } }

68 Pro Tip: Respect the Principle of least surprise

69 Loops

70 Loops If I had more time, I would have written a shorter letter. - Blaise Pascal

71 Loops L µops

72 Loops L µops IDQ 28/56 µops

73 Pro Tip: Craft major loops like good prose

74 Composition

75 Composition Size matters

76 Composition Inlining is THE optimisation. - Cliff Click

77 Composition Single Responsibility

78 Pro Tip: Small atoms can compose to build anything

79 APIs

80 selector.selectnow(); Set<SelectionKey> selectedkeys = selector.selectedkeys(); Iterator<SelectionKey> iter = selectedkeys.iterator(); while (iter.hasnext()) { SelectionKey key = iter.next(); if (key.isreadable()) { process(key.attachment()); // do work } } iter.remove();

81 selector.selectnow(); Set<SelectionKey> selectedkeys = selector.selectedkeys(); Iterator<SelectionKey> iter = selectedkeys.iterator(); while (iter.hasnext()) { SelectionKey key = iter.next(); if (key.isreadable()) { process(key.attachment()); // do work } } iter.remove();

82 // Keep and reuse List<SelectionKey> keys = new ArrayList<>(); selector.selectnow(keys, READABLE); keys.foreach(keyhandler);

83 // Keep and reuse List<SelectionKey> keys = new ArrayList<>(); selector.selectnow(keys, READABLE); keys.foreach(keyhandler);

84 Data

85 Data

86 Data

87 Data

88 Data

89 Data

90 Pro Tip: Embrace Set Theory and FP techniques

91 Performance Testing

92 Define Performance Goals

93 Measuring response time?

94 Response Time Histograms

95 Response Time Histograms Mode

96 Response Time Histograms Mode Median

97 Response Time Histograms Mode Median Mean

98 Response Time Histograms Mode Median Mean

99 Response Time Histograms Mode Median Mean

100 Coordinated Omission

101 HdrHistogram

102 JMH (Java Microbenchmark Harness)

103 CPU Performance Counters

104 Performance test as part of Continuous Integration

105 Build telemetry into production systems

106 AGAIN!!! Build telemetry into production systems

107

108 Counters of: Queue Lengths Concurrent Users Exceptions Transactions - orders, trades Etc. See: Aeron SystemCounters

109 Histograms of: Response Times Service Times Queue Lengths Concurrent Users Etc.

110 In closing

111 Clean => Uncontaminated

112 Good performance is built on a foundation of good design fundamentals

113

114 Questions? It does not matter how intelligent you are, if you guess and that guess cannot be backed up by experimental evidence then it is still a guess. - Richard Feynman