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 238 contents

https://medium.com/expedia-group-tech/creating-monitoring-dashboards-1f3fbe0ae1ac
Creating Monitoring Dashboards (Page last updated September 2020, Added 2020-09-29, Author Nikos Katirtzis, Publisher Expedia). Tips:

• Keep dashboard creation simple, avoid creating complex dashboards that you will never use or alerts that can trigger false-positive notifications.
• Use consistent and meaningful names in your dashboards and alerts.
• Avoid high-cardinality metrics in your dashboards.
• Avoid complex and/or slow queries in your dashboards.
• Monitor the 4 golden signals: Latency (eg p99, p999, ...), Throughput (eg reqs/sec), Errors (eg non-2xx codes), Saturation (eg queue depth, pools active usage and waiting); for the service; also for calls to the service dependencies; and for all infrastructure components.
• Use business metrics for your dashboards in preference to technical metrics.
• Useful JVM metrics to monitor: Process memory, CPU-Usage, Load, Threads, Thread States, File Descriptors, Log Events, JVM Memory Pools (Heap, Non-Heap), Garbage Collection, Classloading, Direct-/Mapped-Buffer, I/O (eg HTTP - Rate, Errors, Duration, TOMCAT/JETTY - Utilisation)

https://dzone.com/articles/3-gc-techniques-to-improve-application-performance
3 GC Techniques to Improve Application Performance (Page last updated September 2020, Added 2020-09-29, Author Tal Weiss, Publisher JavaZone). Tips:

• Memory usage gradually increases until a garbage collection event occurs and the usage drops back down. Heap utilization for referenced objects usually remains steady so the drop should be to more or less the same heap value. If the drop is to ever increasing heap values, this indicates a probable memory leak.
• Long Stop-the-World events (pauses) are usually undesirable as they adversely impact user performance so should be tuned to be shorter.
• Frequent or continuous Stop-the-World events (pauses) usually indicate a memory leak or that the heap is too small for the application.
• GC is a computationally heavy operation; concurrent GC CPU usage is even higher. Choosing the right GC for your application will have the biggest impact on CPU usage.
• Optimize your code so that GCs don't use excessive resources or cause excessive pauses in your application.
• Throughput Collectors are for applications that can trade higher latency to be optimized for high-throughput. The Serial and the Parallel collectors are throughput collectors.
• Low Pause Collectors are for applications that need to optimize for responsiveness (time/event) and strong short-term performance. CMS and G1 are low pause collectors.
• Three primary GC tuning strategies are: Choosing an appropriate collector; adjusting heap sizes; reducing the rate of object allocation and promotion.
• The duration of a Minor GC is reliant on the number of objects that survive the collection. Applications that mostly create short-lived objects can reduce both GC duration and frequency by increasing the size of the young generation.
• Increasing the size of the young generation can lead to a significant increase in objects needing to be copied in survivor spaces, which can make GC longer.
• Predict collection capacities and size collections once on creation, this avoids the underlying array from being copied.
• Process streams directly avoiding intermediate copies of the stream data, or at worst using a small reusable buffer to process the data.
• If objects will survive long enough to reach the old generation, then if they are immutable the young generation GC can ignore them as they can't reference any objects in the young generation, making GC faster.

https://www.youtube.com/watch?v=plYESjZ12hM
Continuous Monitoring with JDK Flight Recorder (Page last updated September 2020, Added 2020-09-29, Author Mikael Vidstedt, Publisher Oracle). Tips:

• JDK Flight Recorder is intended to be used in production and is less than 1% overhead (by default, there are other modes that let you collect more data but that have a higher overhead).
• You can create your own JFR Events wrapping so functionality with Event.begin()...Event.commit().
• Disabled events will likely be completely elided from the generated code by the JIT compiler
• Ways to operated JDK Flight Recorder include: -XX:StartFlightRecording=delay=10s,duration=10m,name=Profiling,filename=recording.jfr or jcmd PID JFR.start and jcmd PID JFR.dump
• There is a jfr command in the JDK bin directory that let's you view JDK Flight Recorder recordings (not a GUI application, Java Mission Control is a GUI application that can view recordings)

https://dzone.com/articles/a-birds-eye-view-on-java-concurrency-frameworks-1
A Bird's-Eye View on Java Concurrency Frameworks (Page last updated February 2019, Added 2020-09-29, Author Vijay Kasiviswanathan, Balasubramanian Muthuvelu, Publisher JavaZone). Tips:

• For in-memory tasks, for best performance the number of threads in your execution pool should be approximately equal to the number of cores.
• For I/O tasks, for best performance the number of threads in your execution pool should be based on the latency of the I/O calls - ideally to optimize throughput, but limited to avoid too much context-switching overhead.
• If an application's req/sec on a node is less than the number of cores available, then an ExecutorService can be used to parallelize tasks and execute code faster. But if an application's req/sec on a node is much higher than the number of cores available, then using ExecutorService to try to parallelize further will make performance worse.
• If the use case is where a thread doesn't need to hold the connection until the client responds, then the async, non-blocking approach should be preferred over synchronous communication. Rather than just waiting, system resources can be put to better use with an asynchronous, non-blocking approach.
• The Disruptor framework performs better when used with event-driven architectural patterns and where there is a single producer and multiple consumers.

Jack Shirazi Back to newsletter 238 contents