JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 253 contents

This month I continue to cover Observability, looking at the four golden signals (latency, saturation, errors, and throughput). Over the last year of covering Observability, I've listed the features that APM tools provide, covered the top 5 reasons for using APM, explained the details of how the various Observability techniques fit together and detailed the 3 pillars of Observability.

This time I'm explaining the four golden signals:

• latency - usually the response time of your requests; latency is often the thing customers are most sensitive to
• saturation - in many cases this is the utilization of a resource; the more loaded (saturated) a resource is, the more cost effective it is, but also the more likely it is to start causing bad performance
• errors - often the first sign that something is about to fail, or has just failed, is an increase in some error rate
• throughput - typically the number of requests per second (or minute, etc) that your service is handling; throughput is the limiting factor of your service

The four golden signals are often co-dependent. A typical scenario is for saturation to be too high on some resource, causing errors to increase, throughput to start failing (decrease) and latency consequently to increase. The four golden signals are often a great starting point for defining your SLOs (service level objectives) which tells you if you are providing adequate service to your customers. A great follow on is to define your Error Budgets. Now on to all the usual newsletter list of links, tips, tools, news and articles, and as usual I've extracted all the tips into this month's tips page including the tips from that error budget article I just mentioned

A note from this newsletter's sponsor

News

Java performance tuning related news

• Good list of performance things that are annoying and some suggested fixes
• A look at the Oracle GCs performance improvements
• G1 heap regions can be set up to 512MB - but ergonomics (automated tuning) won't change them above 32MB so you need to explicitly set the larger size if you think you might benefit. The cases which might benefit include multiple very large objects or overall very large heaps (above 64GB)

Tools

Java performance tuning related tools

• Alibaba Dragonwell JVM openJDK fork optimized for online e-commerce, financial, logistics applications
• Bridge to enable JFR Streaming to opentelemetry
• Arthas, Alibaba's open source Diagnostic tool which let's you troubleshoot production issues for Java applications without modifying code or restarting servers

Articles

• Effortless Profiling on Kubernetes (Eden Federman/Verizon)
• DevOps = Dev + ErrorBudget + Ops (Jack Shirazi/Expedia)
• Quarkus Insights #69: Performance and costs of reactive libraries in Java (Julien Ponge/Quarkusio)

Jack Shirazi

Back to newsletter 253 contents