This v5 host-networked benchmark compares four Redis-compatible engines - Redis, KeyDB, Dragonfly, and Valkey - on a 4 vCPU, 16 GB GitHub Actions Ubuntu runner. Each database runs in Docker host network mode (no NAT overhead), pinned to CPUs 0–3, and configured with 4 I/O threads (or proactors). Update: add PHP Redis Benchmark Results.

• memtier_benchmark (1:15 SET:GET, 512 B payload, Gaussian 3 M-key distribution)
• Client threads = 1, 2, 4, 8
• Clients/thread = 100, Requests/thread = 5 000, Pipeline = 1

Key points

• Prior Docker NAT-networked tests (see readme-v2.md) revealed a Valkey bug: io-threads >1 regressed in performance.
• In this host-networked v5 test, that bug is resolved for Valkey which now scales properly with multiple I/O threads io-threads >1.

Previous benchmarks:

• v1 Redis vs KeyDB vs Dragonfly
• v2 added Valkey, NAT-networked

• Redis 8.0.2
• KeyDB 6.3.4
• Dragonfly 1.30.3
• Valkey 8.1.1

Environment: GitHub Actions Azure Hosted runners with Ubuntu (4 vCPU, 16 GB RAM), Docker host network, CPU-pinning Test tool: memtier_benchmark
Parameters:
• Threads = 4
• Clients/thread = 100
• Requests/thread = 5 000
• Ratio = 1:15 SET:GET
• Data size = 512 Bytes
• Keyspace = 1…3 000 000 (Gaussian)
• IO-threads/Proactor = 4 • Full test results, charts are here

memtier_benchmark \
  -s 127.0.0.1 --protocol=redis -p <port> \
  --ratio=1:15 --clients=100 --requests=5000 \
  --pipeline=1 --data-size=512 \
  --key-pattern=G:G --key-minimum=1 --key-maximum=3000000 \
  --key-median=1500000 --key-stddev=500000 \
  -t 4 --distinct-client-seed --hide-histogram

memtier_benchmark \
  -s 127.0.0.1 --protocol=redis -p <tls-port> --tls \
  --cert=test.crt --key=test.key --cacert=ca.crt --tls-skip-verify \
  --ratio=1:15 --clients=100 --requests=5000 \
  --pipeline=1 --data-size=512 \
  --key-pattern=G:G --key-minimum=1 --key-maximum=3000000 \
  --key-median=1500000 --key-stddev=500000 \
  -t 4 --distinct-client-seed --hide-histogram

Github Hosted runners using Azure VM instances have 4 vCPU threads, so expected that 4 thread results were fastest. With 8 thread results showing the performance when there are not enough vCPU threads to service the load.

Github Hosted runners using Azure VM instances have 4 vCPU threads, so expected that 4 thread results were fastest. With 8 thread results showing the performance when there are not enough vCPU threads to service the load.

Non-TLS: all hit-rates ~5.15 %; absolute hits ∝ throughput

TLS: hit-rates unchanged, hits/s ↓ ~30 % across engines

Insight: Low hit-rate stems from large, random keyspace. Differences in hits/s map directly to raw throughput and TLS overhead.

For 4 threads:

Note: TLS multiplies latency ~1.5–2×, throughput ↓30 %, but relative ranking remains.

Axes (normalized):

• Throughput ↑
• Low Latency (inverted ↑)
• Cache Hit Rate ↑
• Consistency (p99.9 inverted ↑)

Key Insights:

• Dragonfly shows the best scalability with +125% improvement from 1→4 threads
• Redis demonstrates strong scaling at +105% despite starting from a mid-range baseline
• KeyDB and Valkey show more modest scaling improvements around +72-75%
• All databases show diminishing returns beyond 4 threads due to 4-vCPU host limitations

Key Insights:

• Redis provides the most consistent low-latency performance across all percentiles
• Dragonfly offers competitive average latency with slightly higher tail latencies
• Valkey shows the highest latencies, particularly at p99.9 (+49% vs Redis)

TLS Overhead Summary:

• Throughput degradation: 30–34% across all engines
• Average latency increase: 1.4–1.5× (40-52% higher)
• KeyDB shows the most TLS-resilient performance with lowest throughput impact
• Tail latencies remain within acceptable ranges for typical caching workloads

• Peak Throughput (Non-TLS): Redis (125,524 ops/s)
• Peak Throughput (TLS): Redis (83,563 ops/s)
• Best Scalability: Dragonfly (+125% improvement)
• Lowest Latency: Redis (3.18ms avg, 7.65ms p99)
• TLS Resilience: KeyDB (-30.3% throughput, +40% latency)
• Single Thread Champion: KeyDB (66,443 ops/s)

For TLS workloads, budget ~30–35% more CPU and expect ~1.4–1.5× higher latencies.

• Supplemental WordPress Object Cache Test: PHP-based benchmarks (PHP 8.4) using actual WordPress cache patterns
• Test Date: June 8, 2025
• Environment: GitHub Actions Azure Hosted runners with Ubuntu (4 vCPU, 16 GB RAM), Docker host network

In addition to the memtier_benchmark results above, conducted a specialized PHP-based test simulating real WordPress Redis object caching patterns. This test provides insights into how these databases perform with actual WordPress workloads.

Test Configuration:

Tool: Custom PHP WordPress Redis benchmark suite

• Implementation: Native PHP 8.4.7 with Redis extension 6.2.0
• Architecture: Single-threaded PHP application simulating WordPress object cache patterns
• Framework: Custom RedisTestBase class with WordPress-specific implementations

Thread Configuration: 1 thread per database

• redis_io_threads=1 (Redis I/O thread configuration)
• keydb_server_threads=1 (KeyDB server thread configuration)
• dragonfly_proactor_threads=1 (Dragonfly proactor thread configuration)
• valkey_io_threads=1 (Valkey I/O thread configuration)

Test Methodology:

• Operations: 100,000 operations per iteration (configurable via $operations parameter)
• Duration Control: Both operation count and time-based limits (30 seconds max per iteration)
• Read/Write Ratio: 70% reads (GET), 30% writes (SETEX with TTL)
• Cache Warmup: 100 initial keys populated before each test iteration
• Pause Strategy: 0.1ms pause every 1,000 operations to simulate real-world usage patterns

WordPress-Specific Key Patterns:

• Cache Groups: posts, terms, users, options, comments, themes, plugins, transients, site-options
• Key Formats:
  • wp_cache_{group}_{id} (standard WordPress cache keys)
  • {group}_meta_{id} (metadata cache keys)
  • wp_option_{group}_{id} (options cache keys)
  • query_{group}_{hash} (query result cache keys)
  • transient_{group}_{id} (transient cache keys)
  • user_meta_{id}_{group}, post_meta_{id}_{group}, taxonomy_{group}_{id}

WordPress-Realistic Data Values:

• Simple values: Strings, numbers, booleans (typical WordPress cache data)
• Serialized PHP arrays: Post objects, user metadata, complex WordPress data structures
• JSON data: API responses, structured data (100-1000 character payloads)
• Large content: Page cache content (simulated with 50-200 repeated content blocks)
• Variable size: Randomized content sizes reflecting real WordPress cache diversity

TTL (Time-To-Live) Configuration:

• Range: 5 minutes to 24 hours (300-86,400 seconds)
• Distribution: Random TTL assignment per operation
• WordPress-typical: Mirrors real WordPress cache expiration patterns
• Cache Miss Simulation: 20% chance to populate missing keys during read operations

Statistical Methodology:

• Iterations: 13 iterations per database (statistically significant sample size)
• Inter-iteration Pause: 500ms between iterations to ensure clean separation
• Quality Measurement: Coefficient of Variation (CV) analysis
  • Excellent: <2% CV
  • Good: <5% CV
  • Fair: <10% CV
• Confidence Intervals: 95% confidence level with margin of error calculation
• Latency Sampling: Full latency measurement for all 100,000 operations per iteration

Database State Management:

• Pre-test Cleanup: FLUSHALL executed before each database test
• Initial State: Clean database with zero existing keys
• Final State: ~395,000 keys remaining after test completion
• Connection Management: Fresh Redis connections per test iteration

Error Handling & Reliability:

• Exception Tracking: Full error capture with detailed logging
• Operation Counting: Separate tracking of successful operations vs. errors
• Timeout Protection: Maximum duration limits prevent hung tests
• Connection Recovery: Automatic retry mechanisms for transient failures

Performance Metrics Captured:

• Throughput: Operations per second (primary performance indicator)
• Latency Distribution: Average, P95, P99 percentiles in milliseconds
• Error Rates: Failed operations as percentage of total attempts
• Statistical Confidence: CV, standard deviation, confidence intervals
• WordPress-Specific: Estimated page load capacity and concurrent user support

Real-World WordPress Capacity Estimates:

Calculation Notes:

• **Light Pages/sec: Assuming 10 cache operations per page load
• ***Heavy Pages/sec: Assuming 50 cache operations per page load
• ****Concurrent Users: Assuming 30 cache operations per user per second
• Daily calculations: Light pages/sec × 86,400 seconds

Single Thread Comparison (1T Non-TLS):

Performance Characteristics:

1. Redis leads in PHP-based tests with highest ops/sec (16,605 ops/sec, 0.0597ms latency)
2. **Valkey just slightly behind (16,561) and lowest latency (0.0598ms)
3. KeyDB performance gap is significant in PHP tests, showing 15-18% lower throughput than Redis/Valkey
4. Dragonfly shows consistent behavior across both test methodologies with lowest throughput but stable performance

Latency Analysis:

• Sub-millisecond latencies achieved by Redis (0.0597ms) and Valkey (0.0598ms)
• P99 latencies remain excellent across all databases (<200ms, specifically 130-186ms range)

Statistical Reliability:

• All measurements achieved "Good" quality rating (CV < 5%)
• Valkey most consistent with lowest coefficient of variation (2.04%)
• KeyDB and Redis tied for second-best consistency (2.14% CV each)
• 13-iteration methodology provides robust statistical confidence

Database Selection for WordPress:

Capacity Planning:

• Redis: Support ~1,661 light pages/sec or ~332 heavy pages/sec
• Valkey: Support ~1,656 light pages/sec or ~331 heavy pages/sec
• KeyDB: Support ~1,405 light pages/sec or ~281 heavy pages/sec
• Dragonfly: Support ~1,151 light pages/sec or ~230 heavy pages/sec