Repository navigation
Report latency percentiles for single reads and commits - #37
Merged
Merged
Conversation
Adds latency.read and latency.commit. Each operation is its own transaction and is timed separately, and the result file stores p50, p99, p99.9 and max.
Shows the median of each percentile across runs. Result files without latency data render as before.
This was referenced Oct 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #29
Adds two workloads that time every operation on its own, each one a full transaction:
latency.read: 100,000 single incidence lookups, after a warm-uplatency.commit: 5,000 transactions with one node update each, using the run's durabilityEach result stores p50, p99, p99.9 and max in microseconds. The report gets a second table with the median of each percentile across runs. Both workloads also show up in the main table as throughput, and their checksums are compared like the other reads.
No new dependencies: the samples go into a
long[]and get sorted. Result files without latency data render exactly as before; I diffed the report for the existingscale-1-asyncfiles.The first smoke run, at scale 1 with async durability, already shows something the throughput numbers hid. HStore's single-update commits sit at 0.55 to 1.0 ms p50 across three runs, about 10 times slower than HyperGraphDB. The worst commit was between 0.17 s and 7.5 s; the longest GC pause in those runs was 0.7 s. The machine was loaded (load 12 to 20), so I'm not quoting these in the docs, but the commit path needs a look. I'll open a separate issue once I know where the time goes.