RLT — Retrieval Latency & Throughput (Redis)¶
Latency metric family — not comparable to recall pages
RLT measures speed (p50/p95/p99 retrieval latency, throughput, scaling curve, live mixed-workload degradation), a different metric family from the Recall@k/MRR retrieval pages above — the two are not cross-comparable. These are native Popoto (Redis) numbers only; the Valkey run and real Mem0/Zep/vector-DB comparators are a tracked follow-up (see Benchmarking How-To → RLT section). Absolute latency is machine-dependent — read the shape, not the exact millisecond.
Run date: 2026-07-21
Backend: redis
Python: 3.12.13
Platform: macOS-26.5.2-arm64-arm-64bit
CPU count: 10
Latency is
ContextAssembler.assemble()timed end to end (retrieve→rank→inject) — in this harness the per-retrieval and end-to-end-assemble numbers are the same measured call.
Scaling curve — latency vs. corpus size¶
| corpus size | p50 (ms) | p95 (ms) | p99 (ms) | samples | errors |
|---|---|---|---|---|---|
| 1000 | 3.015 | 4.015 | 5.787 | 200 | 0 |
| 5000 | 3.296 | 7.049 | 9.580 | 200 | 0 |
| 10000 | 5.901 | 7.940 | 9.563 | 200 | 0 |
| 20000 | 6.021 | 9.267 | 15.261 | 200 | 0 |
Throughput — queries/sec at corpus size 20000¶
| mode | concurrency | queries/sec | queries | errors |
|---|---|---|---|---|
| serial | 1 | 149.3 | 200 | 0 |
| concurrent | 4 | 293.9 | 200 | 0 |
Live mixed workload — corpus 5000, 4 threads¶
Includes client-side thread-scheduling overhead (thread-based load generator); see the RLT caveat in
docs/benchmarks.md.
| direction | baseline p99 (ms) | degraded p99 (ms) | degradation ratio |
|---|---|---|---|
| read (under write load) | 6.554 | 21.982 | 3.35 |
| write (under read load) | 0.785 | 11.718 | 14.93 |
Notes¶
- Latency measured by timing ContextAssembler.assemble() end to end (retrieve->rank->inject) — assemble_latency and retrieval_latency refer to the same measured call in this harness; there is no separate lower-level retrieval-only API surface to isolate without changing src/popoto/.
- Mixed-workload latency includes client-side thread-scheduling overhead (thread-based load generator); a multi-process load generator would be needed to fully isolate server-only latency (see docs/benchmarks.md RLT caveat).