Tradeoffs, Bad Science, and Polar Bears – The World of Java Optimisation

Slide 1

Slide 1 text

tradeoffs, bad science, and polar bears: the world of java optimisation Holly Cummins Red Hat Devoxx Belgium October 5, 2023

Slide 2

Slide 2 text

#Quarkus @[email protected] why optimise?

Slide 3

Slide 3 text

#Quarkus @[email protected] why optimise?

Slide 4

Slide 4 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time

Slide 5

Slide 5 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic

Slide 6

Slide 6 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load

Slide 7

Slide 7 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load 7% lower conversion rate

Slide 8

Slide 8 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load 7% lower conversion rate

Slide 9

Slide 9 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic 10 ms delay in trading platform 100 ms latency on page load 7% lower conversion rate

Slide 10

Slide 10 text

#Quarkus @[email protected] why optimise? 0.5s extra search page time 20% drop in traffic 10 ms delay in trading platform 10% drop in revenue 100 ms latency on page load 7% lower conversion rate

Slide 11

Slide 11 text

#Quarkus @holly_cummins what is optimising?

Slide 12

Slide 12 text

#Quarkus @[email protected] for whom? when? doing what? “make it go faster”

Slide 13

Slide 13 text

#Quarkus @holly_cummins

Slide 14

Slide 14 text

#Quarkus @holly_cummins performance can be:

Slide 15

Slide 15 text

#Quarkus @holly_cummins performance can be: throughput

Slide 16

Slide 16 text

#Quarkus @holly_cummins performance can be: throughput transactions per second

Slide 17

Slide 17 text

#Quarkus @holly_cummins performance can be: throughput latency transactions per second

Slide 18

Slide 18 text

#Quarkus @holly_cummins performance can be: throughput latency transactions per second start-up time

Slide 19

Slide 19 text

#Quarkus @holly_cummins performance can be: throughput latency transactions per second response time start-up time

Slide 20

Slide 20 text

#Quarkus @holly_cummins performance can be: throughput latency ramp-up time transactions per second response time start-up time

Slide 21

Slide 21 text

#Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time

Slide 22

Slide 22 text

#Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time bandwidth

Slide 23

Slide 23 text

#Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time footprint bandwidth

Slide 24

Slide 24 text

#Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time CPU usage footprint bandwidth

Slide 25

Slide 25 text

#Quarkus @holly_cummins performance can be: throughput latency capacity utilisation ramp-up time transactions per second response time start-up time CPU usage footprint bandwidth

Slide 26

Slide 26 text

#Quarkus @holly_cummins performance can be: throughput latency capacity utilisation … ramp-up time transactions per second response time start-up time CPU usage footprint bandwidth

Slide 27

Slide 27 text

#Quarkus @holly_cummins performance can be: throughput latency capacity utilisation … ramp-up time transactions per second response time start-up time CPU usage footprint bandwidth

Slide 28

Slide 28 text

#Quarkus @[email protected] Never underestimate the bandwidth [throughput] of a station wagon full of tapes hurtling down the highway. –Andrew Tanenbaum, 1981

Slide 29

Slide 29 text

#Quarkus @[email protected] Never underestimate the bandwidth [throughput] of a station wagon full of tapes hurtling down the highway. –Andrew Tanenbaum, 1981 but the latency is terrible …

Slide 30

Slide 30 text

@holly_cummins requirements change

Slide 31

Slide 31 text

@holly_cummins

Slide 32

Slide 32 text

@holly_cummins

Slide 33

Slide 33 text

@holly_cummins

Slide 34

Slide 34 text

@holly_cummins

Slide 35

Slide 35 text

@holly_cummins I am not designed for this.

Slide 36

Slide 36 text

@holly_cummins the world changes

Slide 37

Slide 37 text

#Quarkus @[email protected]

Slide 38

Slide 38 text

#Quarkus @[email protected] -Xmx == $

Slide 39

Slide 39 text

#Quarkus @[email protected] -Xmx == $ footprint

Slide 40

Slide 40 text

#Quarkus @[email protected]

Slide 41

Slide 41 text

#Quarkus @[email protected] which performs better?

Slide 42

Slide 42 text

#Quarkus @[email protected] quarkus + graalvm trading-off flexibility + throughput against startup speed and footprint

Slide 43

Slide 43 text

#Quarkus @[email protected] quarkus + graalvm trading-off flexibility + throughput against startup speed and footprint uhh … are you supposed to shut down applications after using them?

Slide 44

Slide 44 text

#Quarkus @[email protected] aside: quarkus + jvm

Slide 45

Slide 45 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time

Slide 46

Slide 46 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint

Slide 47

Slide 47 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput

Slide 48

Slide 48 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput better developer experience

Slide 49

Slide 49 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput better developer experience

Slide 50

Slide 50 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput better developer experience there is no tradeoff

Slide 51

Slide 51 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput better developer experience there is no tradeoff (only elimination of waste)

Slide 52

Slide 52 text

#Quarkus @[email protected] aside: quarkus + jvm better startup time better footprint better throughput better developer experience there is no tradeoff (only elimination of waste) ok, there is a tradeoff: not optimising for dynamism nobody needs in the cloud

Slide 53

Slide 53 text

#Quarkus @[email protected] “waste” a trade-off where only one side has value

Slide 54

Slide 54 text

#Quarkus @holly_cummins recap: which is “faster?”

Slide 55

Slide 55 text

#Quarkus @holly_cummins GraalVM Quarkus Application recap: which is “faster?”

Slide 56

Slide 56 text

#Quarkus @holly_cummins OpenJDK GraalVM Quarkus Quarkus Application Application recap: which is “faster?”

Slide 57

Slide 57 text

#Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application recap: which is “faster?”

Slide 58

Slide 58 text

#Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application running your application for a long time recap: which is “faster?”

Slide 59

Slide 59 text

#Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application running your application for a long time recap: which is “faster?”

Slide 60

Slide 60 text

@holly_cummins requirements aren’t what we think they are

Slide 61

Slide 61 text

#Quarkus @[email protected] behaviour at idle

Slide 62

Slide 62 text

#Quarkus @[email protected] “optimise for being unused” behaviour at idle

Slide 63

Slide 63 text

#Quarkus @[email protected] “optimise for being unused” useless behaviour at idle

Slide 64

Slide 64 text

#Quarkus @[email protected] 30% of VMs are zombies antithesisgroup.com

Slide 65

Slide 65 text

#Quarkus @holly_cummins how to optimise?

Slide 66

Slide 66 text

#Quarkus @[email protected] find the bottleneck. fix it.

Slide 67

Slide 67 text

#IBM @holly_cummins what could possibly go wrong?!

Slide 68

Slide 68 text

#RedHat @holly_cummins intuition pitfall 1

Slide 69

Slide 69 text

#Quarkus @[email protected] this is not the place for ideas

Slide 70

Slide 70 text

#Quarkus @[email protected] measure, don’t guess.

Slide 71

Slide 71 text

#Quarkus @[email protected] measure the right thing

Slide 72

Slide 72 text

#Quarkus @[email protected] measure the right thing what do your users care about?

Slide 73

Slide 73 text

#RedHat @holly_cummins numbers pitfall 2 (The McNamara Fallacy)

Slide 74

Slide 74 text

#Quarkus @[email protected]

Slide 75

Slide 75 text

#Quarkus @[email protected] leading indicators

Slide 76

Slide 76 text

#Quarkus @[email protected] leading indicators lagging indicators

Slide 77

Slide 77 text

#Quarkus @[email protected] leading indicators we care about them lagging indicators

Slide 78

Slide 78 text

#Quarkus @[email protected] leading indicators we care about them easy to measure lagging indicators

Slide 79

Slide 79 text

#Quarkus @[email protected] leading indicators we care about them easy to measure hard to change lagging indicators

Slide 80

Slide 80 text

#Quarkus @[email protected] leading indicators we care about them easy to measure hard to change lagging indicators easy to change

Slide 81

Slide 81 text

#Quarkus @[email protected] leading indicators we care about them easy to measure hard to change lagging indicators predictive of a thing we care about easy to change

Slide 82

Slide 82 text

#Quarkus @[email protected] leading indicators we care about them easy to measure hard to change lagging indicators predictive of a thing we care about hard to identify easy to change

Slide 83

Slide 83 text

#Quarkus @[email protected] leading indicators we care about them easy to measure hard to change lagging indicators predictive of a thing we care about hard to identify easy to change

Slide 84

Slide 84 text

#Quarkus @[email protected] caution: performance experiments for entertainment purposes only. do not try these at home.

Slide 85

Slide 85 text

#Quarkus @[email protected] 2007

Slide 86

Slide 86 text

#Quarkus @[email protected] bad-ish advice: “reduce time spent in garbage collection”

Slide 87

Slide 87 text

#Quarkus @[email protected] bad-ish advice: “reduce time spent in garbage collection” actually, garbage collection can make your application go faster

Slide 88

Slide 88 text

#Quarkus @[email protected] 2007

Slide 89

Slide 89 text

#Quarkus @[email protected] 2007 compacting every time gc overhead is huge

Slide 90

Slide 90 text

#Quarkus @[email protected] 2007 compacting every time gc overhead is huge

Slide 91

Slide 91 text

#Quarkus @[email protected] 2007 compacting every time gc overhead is huge throughput is … better?!

Slide 92

Slide 92 text

#Quarkus @[email protected] 2021

Slide 93

Slide 93 text

#Quarkus @[email protected] 2021

Slide 94

Slide 94 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xcompactgc

Slide 95

Slide 95 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xcompactgc

Slide 96

Slide 96 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xmx110m -Xms110m -Xnocompactgc

Slide 97

Slide 97 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xmx160m -Xms160m -Xnocompactgc

Slide 98

Slide 98 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xmx300m -Xms300m -Xcompactgc why does the performance stay exactly the same no matter what gc settings I choose?

Slide 99

Slide 99 text

#Quarkus @[email protected] by the way, this is cheating. (remember the ‘bad science’?)

Slide 100

Slide 100 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput

Slide 101

Slide 101 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput tool: GCMV

Slide 102

Slide 102 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s tool: GCMV

Slide 103

Slide 103 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause tool: GCMV

Slide 104

Slide 104 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause total GC time: 12.0s tool: GCMV

Slide 105

Slide 105 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause total GC time: 12.0s 3.6% of time in GC pause tool: GCMV

Slide 106

Slide 106 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause 23.9 GB garbage collected total GC time: 12.0s 3.6% of time in GC pause 13.0 GB garbage collected tool: GCMV

Slide 107

Slide 107 text

#Quarkus @[email protected] -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause 23.9 GB garbage collected 493 transactions/s total GC time: 12.0s 3.6% of time in GC pause 13.0 GB garbage collected 260 transactions/s tool: GCMV

Slide 108

Slide 108 text

Slide 109

Slide 109 text

Slide 110

Slide 110 text

#Quarkus @holly_cummins total GC time: 21.6s 4.1% of time in GC pause 23.9 GB garbage collected 493 transactions/s total GC time: 12.0s 3.6% of time in GC pause 13.0 GB garbage collected 260 transactions/s

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

#Quarkus @[email protected] so wait, what changed to make the app faster? running jmeter on the same machine as the app gives a big speedup!

Slide 118

Slide 118 text

#Quarkus @[email protected] “Any improvements made anywhere besides the bottleneck are an illusion.” – Gene Kim

Slide 119

Slide 119 text

#Quarkus @[email protected] time kills all performance advice (even mine)

Slide 120

Slide 120 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday

Slide 121

Slide 121 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday

Slide 122

Slide 122 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday

Slide 123

Slide 123 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday

Slide 124

Slide 124 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower

Slide 125

Slide 125 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower tradeoff: memory is higher

Slide 126

Slide 126 text

#Quarkus @[email protected] zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower tradeoff: memory is higher java 21 adds generational zgc reduces zgc footprint by 75%

Slide 127

Slide 127 text

#Quarkus @[email protected] the takeaways: gc can improve performance by rearranging the heap find the bottleneck validate advice independently optimise the right thing … for you

Slide 128

Slide 128 text

#RedHat @holly_cummins advice pitfall 3

Slide 129

Slide 129 text

#Quarkus @[email protected] I read it on the internet!

Slide 130

Slide 130 text

#IBM @holly_cummins noooooo! “make one big method because method dispatching is slow”

Slide 131

Slide 131 text

#IBM @holly_cummins noooooo! “re-use your objects to help the garbage collector”

Slide 132

Slide 132 text

#IBM @holly_cummins noooooo! “to tune your JVM, use this command-line:” -server -Xms1g -Xmx1g -XX:PermSize=1g -XX:MaxPermSize=256m -Xmn256m -Xss64k -XX:SurvivorRatio=30 -XX:+UseConcMarkSweepGC -XX: +CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=10 -XX:+ScavengeBeforeFullGC -XX: +CMSScavengeBeforeRemark -XX:+PrintGCDateStamps -verbose:gc -XX: +PrintGCDetails -Dsun.net.inetaddr.ttl=5 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=`date`.hprof -Dcom.sun.management.jmxremote.port=5616 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -server -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewRatio=1 -XX:+UseConcMarkSweepGC

Slide 133

Slide 133 text

#IBM @holly_cummins noooooo! use StringBuilder, never concatenate strings with +=

Slide 134

Slide 134 text

#IBM @holly_cummins noooooo! use StringBuilder, never concatenate strings with += wait, what? yes, right?

Slide 135

Slide 135 text

#Quarkus @[email protected] remember, measure, don’t guess.

Slide 136

Slide 136 text

#Quarkus @[email protected] 2 things ruin advice: • context • time

Slide 137

Slide 137 text

#RedHat @holly_cummins micro-optimisation theatre pitfall 4

Slide 138

Slide 138 text

#Quarkus @[email protected] static string beSlow() { string result = ""; for (int i = 0; i < 314159; i++) { result += getStringData(i); } return result; }

Slide 139

Slide 139 text

#Quarkus @[email protected] @Override public String toString() { String ret = "\n\tMarket Summary at: " + getSummaryDate() + “\n\t\t TSIA:" + getTSIA() + “\n\t\t openTSIA:" + getOpenTSIA() + “\n\t\t gain:" + getGainPercent() + “\n\t\t volume:" + getVolume(); if ((getTopGainers() == null) || (getTopLosers() == null)) { return ret; } ret += "\n\t\t Current Top Gainers:"; Iterator it = getTopGainers().iterator(); while (it.hasNext()) { QuoteDataBean quoteData = it.next(); ret += ("\n\t\t\t" + quoteData.toString()); } ret += "\n\t\t Current Top Losers:"; it = getTopLosers().iterator(); while (it.hasNext()) { QuoteDataBean quoteData = it.next(); ret += ("\n\t\t\t" + quoteData.toString()); } return ret; }

Slide 140

Slide 140 text

Slide 141

Slide 141 text

Slide 142

Slide 142 text

Slide 143

Slide 143 text

#Quarkus @[email protected] let’s make my travel energy-efficient

Slide 144

Slide 144 text

#Quarkus @[email protected] every little helps?

Slide 145

Slide 145 text

#Quarkus @[email protected] every little helps? every optimisation is another optimisation you aren’t doing

Slide 146

Slide 146 text

#Quarkus @[email protected] our platforms help

Slide 147

Slide 147 text

#Quarkus @[email protected] static string beSlow() { string result = ""; for (int i = 0; i < 314159; i++) { result += getStringData(i); } return result; }

Slide 148

Slide 148 text

#Quarkus @[email protected] static string beSlow() { string result = “”; result += getStringData(1); result += getStringData(2); result += getStringData(3); return result; }

Slide 149

Slide 149 text

#Quarkus @[email protected] static string beSlow() { string result = “”; result += getStringData(1); result += getStringData(2); result += getStringData(3); return result; } this is fine

Slide 150

Slide 150 text

#Quarkus @[email protected] the JVM writers have far more time for optimising than you do clean, typical, code runs best

Slide 151

Slide 151 text

#Quarkus @[email protected] but …

Slide 152

Slide 152 text

#Quarkus @[email protected] why did the quarkus 2.0.0 codebase use stringbuilder so much? but …

Slide 153

Slide 153 text

#Quarkus @[email protected] why did the quarkus 2.0.0 codebase use stringbuilder so much? remember, the outside world can change but …

Slide 154

Slide 154 text

#Quarkus @[email protected] remember, measure, don’t guess.

Slide 155

Slide 155 text

#RedHat @holly_cummins the shiny stuff pitfall 5

Slide 156

Slide 156 text

#Quarkus @[email protected] loom

Slide 157

Slide 157 text

#Quarkus @[email protected] loom very good at waiting

Slide 158

Slide 158 text

#Quarkus @[email protected] loom very good at waiting not so good at cpu-bound tasks

Slide 159

Slide 159 text

#Quarkus @[email protected] loom very good at waiting not so good at cpu-bound tasks can interact badly with libraries

Slide 160

Slide 160 text

#Quarkus @[email protected] loom very good at waiting not so good at cpu-bound tasks can interact badly with libraries if a virtual thread gets pinned or does a long cpu process all its friends grind to a halt

Slide 161

Slide 161 text

#Quarkus @[email protected] is thread management really your bottleneck? loom is not a magic “faster thread”

Slide 162

Slide 162 text

#Quarkus @[email protected] remember, measure, don’t guess.

Slide 163

Slide 163 text

#Quarkus @[email protected] remember, measure, don’t guess. -Djdk.tracePinnedThreads

Slide 164

Slide 164 text

#Quarkus @[email protected] remember, measure, don’t guess. -Djdk.tracePinnedThreads @ShouldNotPin (in quarkus tests)

Slide 165

Slide 165 text

#Quarkus @[email protected] remember, measure, don’t guess. -Djdk.tracePinnedThreads @ShouldNotPin (in quarkus tests)

Slide 166

Slide 166 text

#Quarkus @[email protected] learn more

Slide 167

Slide 167 text

#Quarkus @holly_cummins ok, but how to optimise?

Slide 168

Slide 168 text

#Quarkus @[email protected] tools

Slide 169

Slide 169 text

#Quarkus @[email protected] “What you can optimize is limited to what you can observe.” -Susie Xia, Netflix

Slide 170

Slide 170 text

#Quarkus @[email protected] observability

Slide 171

Slide 171 text

#Quarkus @[email protected] * not free this is an incomplete list, because there are a lot of tools out there, and many cost money

Slide 172

Slide 172 text

#Quarkus @[email protected] method profiler * not free this is an incomplete list, because there are a lot of tools out there, and many cost money

Slide 173

Slide 173 text

#Quarkus @[email protected] method profiler VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money

Slide 174

Slide 174 text

#Quarkus @[email protected] method profiler Mission Control VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money

Slide 175

Slide 175 text

#Quarkus @[email protected] method profiler Mission Control VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IntelliJ Profiler

Slide 176

Slide 176 text

#Quarkus @[email protected] method profiler Mission Control VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 177

Slide 177 text

#Quarkus @[email protected] method profiler Mission Control flame graphs VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 178

Slide 178 text

#Quarkus @[email protected] method profiler GC analysis Mission Control flame graphs VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 179

Slide 179 text

#Quarkus @[email protected] method profiler GC analysis Mission Control flame graphs GCMV VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 180

Slide 180 text

#Quarkus @[email protected] method profiler GC analysis heap analysis Mission Control flame graphs GCMV VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 181

Slide 181 text

#Quarkus @[email protected] method profiler GC analysis heap analysis Mission Control flame graphs GCMV VisualVM Eclipse MAT * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 182

Slide 182 text

#Quarkus @[email protected] method profiler GC analysis heap analysis APM Mission Control flame graphs GCMV VisualVM Eclipse MAT * not free this is an incomplete list, because there are a lot of tools out there, and many cost money IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 183

Slide 183 text

Slide 184

Slide 184 text

#Quarkus @[email protected] method profiler GC analysis heap analysis APM Mission Control flame graphs GCMV New Relic* VisualVM Eclipse MAT * not free this is an incomplete list, because there are a lot of tools out there, and many cost money GlowRoot IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 185

Slide 185 text

#Quarkus @[email protected] method profiler GC analysis heap analysis APM Mission Control flame graphs GCMV New Relic* AppDynamics* VisualVM Eclipse MAT * not free this is an incomplete list, because there are a lot of tools out there, and many cost money GlowRoot IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 186

Slide 186 text

#Quarkus @[email protected] method profiler GC analysis heap analysis APM Mission Control flame graphs GCMV New Relic* AppDynamics* VisualVM Dynatrace* Eclipse MAT * not free this is an incomplete list, because there are a lot of tools out there, and many cost money GlowRoot IBM Health Center (for OpenJ9) IntelliJ Profiler

Slide 187

Slide 187 text

Slide 188

Slide 188 text

#Quarkus @[email protected] method profiler

Slide 189

Slide 189 text

#Quarkus @[email protected] method profiler

Slide 190

Slide 190 text

#Quarkus @[email protected] method profiler

Slide 191

Slide 191 text

#Quarkus @[email protected] method profiler

Slide 192

Slide 192 text

#Quarkus @[email protected] method profiler Open Telemetry

Slide 193

Slide 193 text

@holly_cummins you may need to know the whole system context to know what to optimise

Slide 194

Slide 194 text

#Quarkus @[email protected] “Nines don’t matter if your users aren’t happy.” – Charity Majors

Slide 195

Slide 195 text

#Quarkus @[email protected] don’t forget the edges queueing theory helps us understand where the disasters happen

Slide 196

Slide 196 text

#Quarkus @[email protected] “When it comes to IT performance, amateurs look at averages. Professionals look at distributions.” – Avishai Ish-Shalom

Slide 197

Slide 197 text

#Quarkus @[email protected] slow performance can turn into big cloud bills make cloud costs visible to engineers

Slide 198

Slide 198 text

#Quarkus @holly_cummins ok, but you promised bears

Slide 199

Slide 199 text

#Quarkus @[email protected] if you leave the TV on when you’re not using it, you’re a polar bear murderer

Slide 200

Slide 200 text

#Quarkus @[email protected] data centres use 1-2% of the world’s electricity

Slide 201

Slide 201 text

#Quarkus @[email protected] performance optimisation is carbon optimisation

Slide 202

Slide 202 text

#Quarkus @[email protected] cost: leading indicator for carbon performance: leading indicator for carbon

Slide 203

Slide 203 text

#Quarkus @[email protected] example: what our quarkus experiments showed

Slide 204

Slide 204 text

@holly_cummins #RedHat Source: Clement Escoffier cost impact of framework choice Setup: • 800 requests/second, over 20 days • SLA > 99% • AWS instances Assumptions: • Costs are for us-east-1 data centre

Slide 205

Slide 205 text

@holly_cummins #RedHat Setup: • 800 requests/second, over 20 days • SLA > 99% Assumptions: • 50% load • us-east-1 data centre • Teads dataset Source: Clement Escoffier x Teads cloud carbon impact of framework choice carbon impact of framework choice

Slide 206

Slide 206 text

Slide 207

Slide 207 text

@holly_cummins #RedHat capacity Source: John O’Hara Setup: • REST + CRUD • large heap • RAPL energy measurement Assumptions: • US energy mix climate impact of framework choice

Slide 208

Slide 208 text

@holly_cummins #RedHat capacity Source: John O’Hara Setup: • REST + CRUD • large heap • RAPL energy measurement Assumptions: • US energy mix climate impact of framework choice shorter line means lower max throughput

Slide 209

Slide 209 text

Slide 210

Slide 210 text

@holly_cummins #RedHat capacity Source: John O’Hara Setup: • REST + CRUD • large heap • RAPL energy measurement Assumptions: • US energy mix climate impact of framework choice vrrrooom model in action: quarkus on JVM has the smallest footprint … because it has the highest throughput shorter line means lower max throughput higher line means worse carbon footprint

Slide 211

Slide 211 text

#Quarkus @[email protected]

Slide 212

Slide 212 text

#Quarkus @[email protected] we should not waste • electricity • hardware

Slide 213

Slide 213 text

#Quarkus @[email protected] good performance makes us good. we should not waste • electricity • hardware

Slide 214

Slide 214 text

#Quarkus @[email protected] sooo … you can optimise, and it can be fun measure, don’t guess only optimise what matters @holly_cummins #Quarkus Slides