Chronicle JLBH

Table of Contents

• About
• Articles on Java Latency Benchmarking Harness
  • Using JLBH as part of automated performance/performance regression testing

About

Java Latency Benchmark Harness is a tool that allows you to benchmark your code running in context, rather than in a microbenchmark. An excellent introduction can be found in this series of articles.

Since those articles were written the main change has been to allow JLBH to be installed to an event loop, rather than it running in its own thread. To do this, use the JLBH.eventLoopHandler method rather than JLBH.start.

JLBH supports single-thread usage only.

Articles on Java Latency Benchmarking Harness

Introducting JLBH

• What is JLBH

• What was the motivation for JLBH

• Differences between JMH and JLBH

• Quick start guide

Why Code Should be Benchmarked in Context

• A side by side example using JMH and JLBH for Date serialisation

• Measuring Date serialisation in a microbenchmark

• Measuring Date serialisation as part of a proper application

• How to add a probe to your JLBH benchmark

• Understanding the importance of measuring code in context

Accounting for Coordinated Omission

• Running JLBH with and without accounting for coordinated omission

• An example to in numbers the effects of coordinated omission

• A discussion about flow control

The Affects of Throughput on Latency

• A discussion about the effects of throughput on latency

• How use JLBH to measure TCP loopback

• Adding probes to test both halves of the TCP round trip

• Watching the effect of increasing throughput on latency

• Understanding that you have to drop throughput to achieve good latencies at high percentiles.

Benchmarking QuickFix vs ChronicleFix

• Using JLBH to benchmark QuickFIX

• Observing how QuickFix latencies degrade through the percentiles

• Comparing QuickFIX with Chronicle FIX

Using JLBH as part of automated performance/performance regression testing

The net.openhft.chronicle.jlbh.JLBHTest::shouldProvideResultData test shows how the latency percentiles can be extracted and used in the xUnit type of testing frameworks. Ideally, such tests should be run in the environment identical to the production one - it can be achieved by having a special, production-like CI server that is used to execute this type of tests. If the developer’s machine is able to provide sufficient performance, this type of test can be run along with all other tests locally. This, in turn allows the performance testing to be part of the regular TDD cycle, which helps to discover design flaws earlier and often, lowering the development cost of the latency-sensitive applications.