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

Welcome to the Java optimisation jungle. Why can’t we “just make it go faster”? It turns out, in most cases, we need to first work out “faster for whom?” and “why do we want to go faster?” and “what even is faster?” This talk introduces the basic principles of optimisation, before bouncing through the pitfalls of optimisation; why the exact same techniques which make Quarkus rocket-fast used to be a terrible idea fifteen years ago, why fast benchmarks make for slow programs, why project loom may not be the speedup you’re hoping for, and why even though it can be easy to get wrong, optimisation really really matters. Along the way we’ll talk about measuring things, bad advice, garbage collection, and climate change.

Transcript

1. tradeoffs, bad science, and polar bears: the world of java optimisation Holly Cummins Red Hat Devoxx Belgium October 5, 2023
2. #Quarkus @holly_cummins@hachyderm.io why optimise?
3. #Quarkus @holly_cummins@hachyderm.io why optimise?
4. #Quarkus @holly_cummins@hachyderm.io why optimise? 0.5s extra search page time
5. #Quarkus @holly_cummins@hachyderm.io why optimise? 0.5s extra search page time 20% drop in traffic
6. #Quarkus @holly_cummins@hachyderm.io why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load
7. #Quarkus @holly_cummins@hachyderm.io why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load 7% lower conversion rate
8. #Quarkus @holly_cummins@hachyderm.io why optimise? 0.5s extra search page time 20% drop in traffic 100 ms latency on page load 7% lower conversion rate
9. #Quarkus @holly_cummins@hachyderm.io 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
10. #Quarkus @holly_cummins@hachyderm.io 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
11. #Quarkus @holly_cummins what is optimising?
12. #Quarkus @holly_cummins@hachyderm.io for whom? when? doing what? “make it go faster”
13. #Quarkus @holly_cummins
14. #Quarkus @holly_cummins performance can be:
15. #Quarkus @holly_cummins performance can be: throughput
16. #Quarkus @holly_cummins performance can be: throughput transactions per second
17. #Quarkus @holly_cummins performance can be: throughput latency transactions per second
18. #Quarkus @holly_cummins performance can be: throughput latency transactions per second start-up time
19. #Quarkus @holly_cummins performance can be: throughput latency transactions per second response time start-up time
20. #Quarkus @holly_cummins performance can be: throughput latency ramp-up time transactions per second response time start-up time
21. #Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time
22. #Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time bandwidth
23. #Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time footprint bandwidth
24. #Quarkus @holly_cummins performance can be: throughput latency capacity ramp-up time transactions per second response time start-up time CPU usage footprint bandwidth
25. #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
26. #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
27. #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
28. #Quarkus @holly_cummins@hachyderm.io Never underestimate the bandwidth [throughput] of a station wagon full of tapes hurtling down the highway. –Andrew Tanenbaum, 1981
29. #Quarkus @holly_cummins@hachyderm.io Never underestimate the bandwidth [throughput] of a station wagon full of tapes hurtling down the highway. –Andrew Tanenbaum, 1981 but the latency is terrible …
30. @holly_cummins requirements change
31. @holly_cummins
32. @holly_cummins
33. @holly_cummins
34. @holly_cummins
35. @holly_cummins I am not designed for this.
36. @holly_cummins the world changes
37. #Quarkus @holly_cummins@hachyderm.io
38. #Quarkus @holly_cummins@hachyderm.io -Xmx == $
39. #Quarkus @holly_cummins@hachyderm.io -Xmx == $ footprint
40. #Quarkus @holly_cummins@hachyderm.io
41. #Quarkus @holly_cummins@hachyderm.io which performs better?
42. #Quarkus @holly_cummins@hachyderm.io quarkus + graalvm trading-off flexibility + throughput against startup speed and footprint
43. #Quarkus @holly_cummins@hachyderm.io quarkus + graalvm trading-off flexibility + throughput against startup speed and footprint uhh … are you supposed to shut down applications after using them?
44. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm
45. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time
46. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint
47. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint better throughput
48. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint better throughput better developer experience
49. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint better throughput better developer experience
50. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint better throughput better developer experience there is no tradeoff
51. #Quarkus @holly_cummins@hachyderm.io aside: quarkus + jvm better startup time better footprint better throughput better developer experience there is no tradeoff (only elimination of waste)
52. #Quarkus @holly_cummins@hachyderm.io 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
53. #Quarkus @holly_cummins@hachyderm.io “waste” a trade-off where only one side has value
54. #Quarkus @holly_cummins recap: which is “faster?”
55. #Quarkus @holly_cummins GraalVM Quarkus Application recap: which is “faster?”
56. #Quarkus @holly_cummins OpenJDK GraalVM Quarkus Quarkus Application Application recap: which is “faster?”
57. #Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application recap: which is “faster?”
58. #Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application running your application for a long time recap: which is “faster?”
59. #Quarkus @holly_cummins ephemeral or serverless OpenJDK GraalVM Quarkus Quarkus Application Application running your application for a long time recap: which is “faster?”
60. @holly_cummins requirements aren’t what we think they are
61. #Quarkus @holly_cummins@hachyderm.io behaviour at idle
62. #Quarkus @holly_cummins@hachyderm.io “optimise for being unused” behaviour at idle
63. #Quarkus @holly_cummins@hachyderm.io “optimise for being unused” useless behaviour at idle
64. #Quarkus @holly_cummins@hachyderm.io 30% of VMs are zombies antithesisgroup.com
65. #Quarkus @holly_cummins how to optimise?
66. #Quarkus @holly_cummins@hachyderm.io find the bottleneck. fix it.
67. #IBM @holly_cummins what could possibly go wrong?!
68. #RedHat @holly_cummins intuition pitfall 1
69. #Quarkus @holly_cummins@hachyderm.io this is not the place for ideas
70. #Quarkus @holly_cummins@hachyderm.io measure, don’t guess.
71. #Quarkus @holly_cummins@hachyderm.io measure the right thing
72. #Quarkus @holly_cummins@hachyderm.io measure the right thing what do your users care about?
73. #RedHat @holly_cummins numbers pitfall 2 (The McNamara Fallacy)
74. #Quarkus @holly_cummins@hachyderm.io
75. #Quarkus @holly_cummins@hachyderm.io leading indicators
76. #Quarkus @holly_cummins@hachyderm.io leading indicators lagging indicators
77. #Quarkus @holly_cummins@hachyderm.io leading indicators we care about them lagging indicators
78. #Quarkus @holly_cummins@hachyderm.io leading indicators we care about them easy to measure lagging indicators
79. #Quarkus @holly_cummins@hachyderm.io leading indicators we care about them easy to measure hard to change lagging indicators
80. #Quarkus @holly_cummins@hachyderm.io leading indicators we care about them easy to measure hard to change lagging indicators easy to change
81. #Quarkus @holly_cummins@hachyderm.io leading indicators we care about them easy to measure hard to change lagging indicators predictive of a thing we care about easy to change
82. #Quarkus @holly_cummins@hachyderm.io 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
83. #Quarkus @holly_cummins@hachyderm.io 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
84. #Quarkus @holly_cummins@hachyderm.io caution: performance experiments for entertainment purposes only. do not try these at home.
85. #Quarkus @holly_cummins@hachyderm.io 2007
86. #Quarkus @holly_cummins@hachyderm.io bad-ish advice: “reduce time spent in garbage collection”
87. #Quarkus @holly_cummins@hachyderm.io bad-ish advice: “reduce time spent in garbage collection” actually, garbage collection can make your application go faster
88. #Quarkus @holly_cummins@hachyderm.io 2007
89. #Quarkus @holly_cummins@hachyderm.io 2007 compacting every time gc overhead is huge
90. #Quarkus @holly_cummins@hachyderm.io 2007 compacting every time gc overhead is huge
91. #Quarkus @holly_cummins@hachyderm.io 2007 compacting every time gc overhead is huge throughput is … better?!
92. #Quarkus @holly_cummins@hachyderm.io 2021
93. #Quarkus @holly_cummins@hachyderm.io 2021
94. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xcompactgc
95. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xcompactgc
96. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xmx110m -Xms110m -Xnocompactgc
97. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput -Xmx160m -Xms160m -Xnocompactgc
98. #Quarkus @holly_cummins@hachyderm.io -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?
99. #Quarkus @holly_cummins@hachyderm.io by the way, this is cheating. (remember the ‘bad science’?)
100. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput
101. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput tool: GCMV
102. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s tool: GCMV
103. #Quarkus @holly_cummins@hachyderm.io -verbose:gc -Xverbosegclog:gclog.xml -Xgcpolicy:optthruput total GC time: 21.6s 4.1% of time in GC pause tool: GCMV
104. #Quarkus @holly_cummins@hachyderm.io -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
105. #Quarkus @holly_cummins@hachyderm.io -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
106. #Quarkus @holly_cummins@hachyderm.io -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
107. #Quarkus @holly_cummins@hachyderm.io -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
108. #Quarkus @holly_cummins@hachyderm.io -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
109. #Quarkus @holly_cummins@hachyderm.io -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
110. #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
111. #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
112. #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 leading indicator
113. #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 leading indicator
114. #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 leading indicator lagging indicator
115. #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 leading indicator lagging indicator ?
116. #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 leading indicator lagging indicator ? ?
117. #Quarkus @holly_cummins@hachyderm.io so wait, what changed to make the app faster? running jmeter on the same machine as the app gives a big speedup!
118. #Quarkus @holly_cummins@hachyderm.io “Any improvements made anywhere besides the bottleneck are an illusion.” – Gene Kim
119. #Quarkus @holly_cummins@hachyderm.io time kills all performance advice (even mine)
120. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday
121. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday
122. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday
123. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday
124. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower
125. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower tradeoff: memory is higher
126. #Quarkus @holly_cummins@hachyderm.io zgc Brian Goetz, yesterday tradeoff: throughput is ~2% lower tradeoff: memory is higher java 21 adds generational zgc reduces zgc footprint by 75%
127. #Quarkus @holly_cummins@hachyderm.io the takeaways: gc can improve performance by rearranging the heap find the bottleneck validate advice independently optimise the right thing … for you
128. #RedHat @holly_cummins advice pitfall 3
129. #Quarkus @holly_cummins@hachyderm.io I read it on the internet!
130. #IBM @holly_cummins noooooo! “make one big method because method dispatching is slow”
131. #IBM @holly_cummins noooooo! “re-use your objects to help the garbage collector”
132. #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
133. #IBM @holly_cummins noooooo! use StringBuilder, never concatenate strings with +=
134. #IBM @holly_cummins noooooo! use StringBuilder, never concatenate strings with += wait, what? yes, right?
135. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess.
136. #Quarkus @holly_cummins@hachyderm.io 2 things ruin advice: • context • time
137. #RedHat @holly_cummins micro-optimisation theatre pitfall 4
138. #Quarkus @holly_cummins@hachyderm.io static string beSlow() { string result = ""; for (int i = 0; i < 314159; i++) { result += getStringData(i); } return result; }
139. #Quarkus @holly_cummins@hachyderm.io @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<QuoteDataBean> 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; }
140. #Quarkus @holly_cummins@hachyderm.io @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<QuoteDataBean> 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; }
141. #Quarkus @holly_cummins@hachyderm.io @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<QuoteDataBean> 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; }
142. #Quarkus @holly_cummins@hachyderm.io @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<QuoteDataBean> 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; } this never gets called
143. #Quarkus @holly_cummins@hachyderm.io let’s make my travel energy-efficient
144. #Quarkus @holly_cummins@hachyderm.io every little helps?
145. #Quarkus @holly_cummins@hachyderm.io every little helps? every optimisation is another optimisation you aren’t doing
146. #Quarkus @holly_cummins@hachyderm.io our platforms help
147. #Quarkus @holly_cummins@hachyderm.io static string beSlow() { string result = ""; for (int i = 0; i < 314159; i++) { result += getStringData(i); } return result; }
148. #Quarkus @holly_cummins@hachyderm.io static string beSlow() { string result = “”; result += getStringData(1); result += getStringData(2); result += getStringData(3); return result; }
149. #Quarkus @holly_cummins@hachyderm.io static string beSlow() { string result = “”; result += getStringData(1); result += getStringData(2); result += getStringData(3); return result; } this is fine
150. #Quarkus @holly_cummins@hachyderm.io the JVM writers have far more time for optimising than you do clean, typical, code runs best
151. #Quarkus @holly_cummins@hachyderm.io but …
152. #Quarkus @holly_cummins@hachyderm.io why did the quarkus 2.0.0 codebase use stringbuilder so much? but …
153. #Quarkus @holly_cummins@hachyderm.io why did the quarkus 2.0.0 codebase use stringbuilder so much? remember, the outside world can change but …
154. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess.
155. #RedHat @holly_cummins the shiny stuff pitfall 5
156. #Quarkus @holly_cummins@hachyderm.io loom
157. #Quarkus @holly_cummins@hachyderm.io loom very good at waiting
158. #Quarkus @holly_cummins@hachyderm.io loom very good at waiting not so good at cpu-bound tasks
159. #Quarkus @holly_cummins@hachyderm.io loom very good at waiting not so good at cpu-bound tasks can interact badly with libraries
160. #Quarkus @holly_cummins@hachyderm.io 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
161. #Quarkus @holly_cummins@hachyderm.io is thread management really your bottleneck? loom is not a magic “faster thread”
162. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess.
163. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess. -Djdk.tracePinnedThreads
164. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess. -Djdk.tracePinnedThreads @ShouldNotPin (in quarkus tests)
165. #Quarkus @holly_cummins@hachyderm.io remember, measure, don’t guess. -Djdk.tracePinnedThreads @ShouldNotPin (in quarkus tests)
166. #Quarkus @holly_cummins@hachyderm.io learn more
167. #Quarkus @holly_cummins ok, but how to optimise?
168. #Quarkus @holly_cummins@hachyderm.io tools
169. #Quarkus @holly_cummins@hachyderm.io “What you can optimize is limited to what you can observe.” -Susie Xia, Netflix
170. #Quarkus @holly_cummins@hachyderm.io observability
171. #Quarkus @holly_cummins@hachyderm.io * not free this is an incomplete list, because there are a lot of tools out there, and many cost money
172. #Quarkus @holly_cummins@hachyderm.io method profiler * not free this is an incomplete list, because there are a lot of tools out there, and many cost money
173. #Quarkus @holly_cummins@hachyderm.io method profiler VisualVM * not free this is an incomplete list, because there are a lot of tools out there, and many cost money
174. #Quarkus @holly_cummins@hachyderm.io 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
175. #Quarkus @holly_cummins@hachyderm.io 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
176. #Quarkus @holly_cummins@hachyderm.io 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
177. #Quarkus @holly_cummins@hachyderm.io 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
178. #Quarkus @holly_cummins@hachyderm.io 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
179. #Quarkus @holly_cummins@hachyderm.io 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
180. #Quarkus @holly_cummins@hachyderm.io 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
181. #Quarkus @holly_cummins@hachyderm.io 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
182. #Quarkus @holly_cummins@hachyderm.io 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
183. #Quarkus @holly_cummins@hachyderm.io 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 GlowRoot IBM Health Center (for OpenJ9) IntelliJ Profiler
184. #Quarkus @holly_cummins@hachyderm.io 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
185. #Quarkus @holly_cummins@hachyderm.io 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
186. #Quarkus @holly_cummins@hachyderm.io 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
187. #Quarkus @holly_cummins@hachyderm.io 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
188. #Quarkus @holly_cummins@hachyderm.io method profiler
189. #Quarkus @holly_cummins@hachyderm.io method profiler
190. #Quarkus @holly_cummins@hachyderm.io method profiler
191. #Quarkus @holly_cummins@hachyderm.io method profiler
192. #Quarkus @holly_cummins@hachyderm.io method profiler Open Telemetry
193. @holly_cummins you may need to know the whole system context to know what to optimise
194. #Quarkus @holly_cummins@hachyderm.io “Nines don’t matter if your users aren’t happy.” – Charity Majors
195. #Quarkus @holly_cummins@hachyderm.io don’t forget the edges queueing theory helps us understand where the disasters happen
196. #Quarkus @holly_cummins@hachyderm.io “When it comes to IT performance, amateurs look at averages. Professionals look at distributions.” – Avishai Ish-Shalom
197. #Quarkus @holly_cummins@hachyderm.io slow performance can turn into big cloud bills make cloud costs visible to engineers
198. #Quarkus @holly_cummins ok, but you promised bears
199. #Quarkus @holly_cummins@hachyderm.io if you leave the TV on when you’re not using it, you’re a polar bear murderer
200. #Quarkus @holly_cummins@hachyderm.io data centres use 1-2% of the world’s electricity
201. #Quarkus @holly_cummins@hachyderm.io performance optimisation is carbon optimisation
202. #Quarkus @holly_cummins@hachyderm.io cost: leading indicator for carbon performance: leading indicator for carbon
203. #Quarkus @holly_cummins@hachyderm.io example: what our quarkus experiments showed
204. @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
205. @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
206. @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 economic model in action: the cost and carbon metrics are (roughly) the same
207. @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
208. @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
209. @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 higher line means worse carbon footprint
210. @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
211. #Quarkus @holly_cummins@hachyderm.io
212. #Quarkus @holly_cummins@hachyderm.io we should not waste • electricity • hardware
213. #Quarkus @holly_cummins@hachyderm.io good performance makes us good. we should not waste • electricity • hardware
214. #Quarkus @holly_cummins@hachyderm.io sooo … you can optimise, and it can be fun measure, don’t guess only optimise what matters @holly_cummins #Quarkus Slides