The probe performance measurement

Generated page

Model gemma-mtp, commit ef58254ca7be, 2026-08-16, sources: 6. Edit the code or the hand-written documentation instead.

The entry point for manual performance verification, comparing different execution modes and scaling across multiple callers. It reads the broker address from the BOOBLIK_BROKER environment variable Probe.kt:52-56 and iterates through a set of caller counts (1, 8, and 64) to measure throughput Probe.kt:65-75.

The `Mode` enumeration

The three execution strategies: DIRECT (no accumulator), BATCHED (awaited), and BATCHED_NOT_AWAITED (pipelined).

Mode	Description
`DIRECT`	Every record itsown request, awaited before the next. What a caller without one does. `Probe.kt:79-81`
`BATCHED`	Through the accumulator, still awaited before the next — a request handler's pattern. `Probe.kt:83`
`BATCHED_NOT_AWAITED`	Through the accumulator, awaited at the end. The case the accumulator exists for. `Probe.kt:86-92`

The `verify` mechanism

Integrity checks ensuring every record is accounted for and that all produced offsets are distinct. The verify function checks if the number of returned offsets matches the expected count and ensures no two records were given the same offset Probe.kt:173-185.

The `SubscriptionProbe` lifecycle

Measuring the cost of IDLE vs THROUGHPUT modes and the performance overhead of the Flow abstraction via bare fetch loop, cold flow { }, and buffer(). The probe measures the number of fetch requests answered by the server during a specific duration SubscriptionProbe.kt:208-225 and compares three rungs of the readThreeWays ladder to isolate the cost of the Flow machinery and the decoupling provided by buffer() SubscriptionProbe.kt:289-329.

The `MeasurementDir` constraint

The refusal to run measurements on volatile filesystems (like tmpfs or ramfs) to prevent measuring memory instead of disk. The create function checks the file store type and throws an IllegalStateException if the directory is on a volatile filesystem, as fsync is a no-op there MeasurementDir.kt:39-48.

Key files

File	Lines	What is there
`…/conformance/Probe.kt`	`65-75`	The main loop iterating through different caller counts for benchmarking.
`…/probe/SubscriptionProbe.kt`	`289-329`	The implementation of the three-way comparison for Flow abstraction overhead.
`…/benchmark/MeasurementDir.kt`	`39-48`	Logic to prevent measurements on volatile filesystems like `tmpfs`.

Behaviour that surprises

The SubscriptionProbe can report that a Flow is faster than the loop it wraps if the comparison is not performed in sequence, because callbackFlow introduces real concurrency (decoupling) that a bare loop lacks SubscriptionProbe.kt:272-277.
The MeasurementDir will actively refuse to run a test if it detects a tmpfs or ramfs filesystem to avoid reporting "fiction" numbers where fsync is a no-op MeasurementDir.kt:32-48.