Testing · evidence · limitations
Clients and integrations
End-to-end API behavior and isolated server benchmarks answer different questions. These tests do not measure a universal Ruvio server throughput ceiling.
Two-host API scenario · 2026-10-03
Goal: exercise cache, idempotency and rate limiting together over a .NET client. Environment: two-vCPU Ubuntu 24.04 API host; k6 0.54.0, two 120-second stages at an offered 200 iterations/s, 30-second gap, 40/30/30 random operation mix. Ruvio always and Redis AOF appendfsync always; native IDEM/LIMIT on Ruvio versus semantic Lua equivalents on Redis. Result: 24,001 iterations per backend; 48,002 functional checks passed, no dropped iterations or failed HTTP requests. Ruvio mean HTTP latency 3.221 ms and p95 6.206 ms; Redis 2.608 ms and 5.180 ms. Redis was faster in this bounded run.
Limit: adapter-level scenario, not production middleware parity or peak capacity. Client, transport and server time are combined; exported storage histogram counts do not fully reconcile with k6 request counts. A different memory-mode run completed the same offered rate, but does not isolate the effect of persistence. Earlier runs used older client/server variants; do not combine their latency numbers as one benchmark.
Durable result and interpretation Memory-mode result Committed k6 summary Scenario setup
Which checks are automatic?
The automatic gate executes first-party Rust and .NET client tests and a live two-shard Rust routing smoke. The separate integration-package workflow is manually dispatched. See its test commands and the package-specific readmes before interpreting an integration test count; this page does not claim all packages passed on this revision.