Benchmarks

Swytch is designed for production workloads where performance and durability both matter. This page presents benchmark results comparing Swytch to Redis under various conditions.

All benchmarks were run on:

• CPU: AMD Ryzen 5 3600 (6 cores / 12 threads)
• RAM: 64GB DDR4
• Storage: Samsung NVMe in RAID0
• OS: Ubuntu 24.04
• Connection: Unix socket (lowest latency)

Swytch’s performance advantage comes from a lock-free architecture designed from the ground up for multicore systems:

• Lock-free transactional index: Concurrent reads and writes proceed without blocking each other. No thread waits for another to release a lock.

• Novel eviction algorithm: A self-tuning, lock-free eviction system that adapts to your workload in real-time. This is an area of active research—expect further improvements as we refine the algorithm.

• FASTER-inspired storage: The persistent storage layer uses techniques from Microsoft’s FASTER research project, enabling lock-free append-only writes with indexed lookups that don’t block the hot path.

Redis processes commands single-threaded. Swytch processes commands in parallel across all available cores while maintaining the same consistency guarantees. The result: linear scaling with core count instead of a single-threaded bottleneck.

Using redis-benchmark with 4 threads, 100 clients, 500K operations per command, 16-byte values, Unix socket:

Swytch achieves 2x+ throughput on most operations while providing full per-operation durability. Redis was configured with appendfsync everysec (1 second of potential data loss).

High-throughput pipeline test (4 threads, 10 clients, pipeline 50, 10 M write operations):

Large value test (4 threads, 20 clients, 4KB values, 1:10 write:read ratio, rate-limited):

Zipf 0.99 distribution (4 threads, 50 clients, 256-byte values, 1:10 write:read ratio):

High-concurrency pipeline (8 threads, 100 clients, pipeline 10, Zipf 1.1, 128-byte values):

We replayed production cache traces from published academic datasets to measure real-world hit rates and backend impact. These traces capture actual access patterns from hyperscale deployments.

Swytch can use disk as extended storage, not just for durability. While Redis evicts data when RAM fills up, Swytch transparently tiers cold data to disk and serves it with minimal latency penalty. This is ideal for key-value store workloads where you want all data accessible, or highly cacheable workloads with predictable access patterns.

Alibaba Block Storage Trace (10MB RAM, 8.6M operations, appendfsync everysec):

Redis is RAM-only: when the 10MB limit is reached, it evicts data aggressively, resulting in a 33% hit rate. Swytch keeps hot data in RAM and tiers the rest to NVMe, achieving near-perfect hit rates with **no meaningful latency penalty ** (70µs avg).

When to use this mode:

• Key-value store replacing a database, where all keys should remain accessible
• Workloads with predictable, cacheable access patterns
• Situations where disk is cheap but cache misses are expensive

When NOT to use this mode:

• Traditional cache-aside patterns where misses are expected and acceptable
• Workloads with unbounded key growth (disk isn’t infinite either)

For pure caching workloads, see the memory-constrained benchmarks below where both systems operate under the same RAM limits.

When both systems are constrained to the same RAM limit—a fair apples-to-apples comparison—Swytch’s adaptive eviction algorithm outperforms Redis LRU.

Alibaba Block Storage (18MB cache limit, 48-hour trace):

Swytch maintains a 9 percentage point advantage in hit rate under identical memory constraints. The algorithm accounts for access frequency, recency, and object size—not just recency like Redis LRU.

When memory is sufficient for the working set, both systems achieve similar hit rates, but Swytch maintains its throughput advantage.

Alibaba Block Storage (40GB cache, 48-hour trace, appendfsync everysec):

Twitter Cluster (40GB cache, 20-minute trace, appendfsync everysec):

Hit rates are effectively identical. Choose Swytch for the durability guarantees without sacrificing performance.

Tencent Photo CDN (40GB cache, 5.5M operations, appendfsync everysec):

With highly variable object sizes (typical of CDN workloads), Swytch’s size-aware eviction provides a modest but consistent advantage.

Swytch consistently delivers more requests in the sub-100µs bucket:

GET Latency (Alibaba trace, adequate memory):

GET Latency (Alibaba trace, memory-constrained 18MB):

Under memory pressure, Swytch trades slightly more latency variance for dramatically better hit rates—a worthwhile tradeoff when each miss costs a database round-trip.

Swytch’s tiered storage provides full durability (10 ms max data loss) with minimal performance impact.

Test: memtier_benchmark, 4 threads, 50 clients, 256-byte values, Unix socket

Write-through mode (full durability) adds minimal latency overhead. Ghost mode (write-back) offers higher write throughput when eventual persistence is acceptable.

Swytch delivers higher throughput, lower latency, and better cache efficiency under memory pressure—all while providing stronger durability guarantees than Redis. For workloads that benefit from disk-tiered storage, Swytch can serve as a high-performance key-value store with near-perfect data availability.

# Single operations (matches our test parameters)
redis-benchmark -s /path/to/socket \
  -t ping_inline,ping_mbulk,set,get,incr,lpush,rpush,lpop,rpop,sadd,hset,spop,lrange_100,lrange_300,lrange_500,lrange_600,mset \
  --csv -d 16 --threads 4 -c 100 -n 500000

# High-throughput pipeline (write-heavy)
memtier_benchmark --protocol=redis -S /path/to/socket \
  -t 4 -c 10 --pipeline=50 \
  --key-minimum=1 --key-maximum=10000000 \
  --key-pattern=P:P --ratio=1:0 -n allkeys \
  --hide-histogram

# Large values with rate limiting
memtier_benchmark --protocol=redis -S /path/to/socket \
  -t 4 -c 20 --pipeline=1 --rate-limiting=50000 \
  --key-minimum=1 --key-maximum=2000000 \
  --ratio=1:10 -n 200000 --data-size=4096 \
  --hide-histogram

# Zipf distribution (hot keys)
memtier_benchmark --protocol=redis -S /path/to/socket \
  --threads=4 --clients=50 --requests=100000 \
  --ratio=1:10 --key-pattern=Z:Z \
  --key-zipf-exp=0.99 --key-maximum=100000 \
  --data-size=256 --hide-histogram

# High-concurrency pipeline
memtier_benchmark --protocol=redis -S /path/to/socket \
  --threads=8 --clients=100 --requests=100000 \
  --ratio=1:20 --key-pattern=Z:Z \
  --key-zipf-exp=1.1 --key-maximum=50000 \
  --data-size=128 --pipeline=10 --hide-histogram

Our trace-bench tool replays real production traces against both Redis and Swytch:

# Memory-constrained with persistence
./trace-bench --real --real-vsize \
  --swytch-path ./swytch \
  --time-limit 48h \
  --gb 0.010 --ram 1 --cpus 4 \
  --noscale \
  --trace alibabaBlock_277.oracleGeneral.zst \
  --persistent-everysec

# Adequate memory
./trace-bench --real --real-vsize \
  --swytch-path ./swytch \
  --time-limit 48h \
  --gb 40 --ram 50 --cpus 16 \
  --noscale \
  --trace alibabaBlock_277.oracleGeneral.zst

Trace files are available from the CacheMon cache_dataset project.