DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
| Distribution | Key value |
|---|---|
| NONE | null |
| RANGE | Integer.toString(recordIndex % keyRange) |
RANDOM | Integer.toString(random.nextInt(keyRange)) |
Performance note: The random distribution reuses a single SplittableRandom instance that is already constructed for payload generation. SplittableRandom.nextInt() is a lightweight, non-thread-safe PRNG with no allocation overhead, so key generation adds negligible latency to the hot path.
Validation
ConfigPostProcessor enforces mutual consistency between the two new arguments:
...
All remaining tests should pass, and new unit test.
Rejected Alternatives
UUID keys for random distribution
An alternative design would use UUID.randomUUID().toString() as the key for the random distribution, providing globally unique keys with no repeated values across the entire benchmark run.
This was rejected for two reasons:
- Unbounded key space defeats the purpose. The primary use case for random keys is to benchmark workloads with a known, bounded key space (e.g., 10,000 customer IDs). UUID keys give every record a unique key, making partition distribution identical to round-robin and eliminating the ability to model hot-key or skewed-partition scenarios.
- Performance overhead.
UUID.randomUUID()uses SecureRandom internally, which is significantly slower thanSplittableRandom.nextInt()and could become a bottleneck in high-throughput benchmarks — the opposite of what a perf tool should do.
Engineers who genuinely need globally unique keys can use --key-distribution random --message-key-range <large-number> (e.g., 2^31−1) to approximate the same effect without the overhead.n/a