Tair (Redis® OSS-Compatible):Performance whitepaper of ESSD-based instances

Test scenarios

The tests cover two scenarios that produce significantly different performance characteristics:

• Memory size larger than data volume — Most data fits in memory (memory:data ratio ≈ 7:1). Read requests are served from memory with minimal disk access.

• Data volume larger than memory size — Only part of the dataset is cached. Most requests require disk reads or writes (memory:data ratio ≈ 1:4).

Expect significantly lower QPS in Scenario 2 compared to Scenario 1 for the same instance type. This difference is expected behavior due to the increased disk access required when data exceeds available memory.

Step 1: Load data

./bin/ycsb load redis -s -P workloads/workloada \
  -p "redis.host=${ip}" \
  -p "redis.port=${port}" \
  -p "recordcount=${recordcount}" \
  -p "operationcount=${recordcount}" \
  -p "redis.timeout=${timeout}" \
  -p "redis.command_group=${command_group}" \
  -p "fieldcount=${fieldcount}" \
  -p "fieldlength=${fieldlength}" \
  -threads ${threads}

sleep ${load_sleep_time}   # Allow data to flush to disk before reading

Step 2: Test read throughput (uniform distribution)

./bin/ycsb run redis -s -P workloads/workloadc \
  -p "redis.host=${ip}" \
  -p "redis.port=${port}" \
  -p "recordcount=${recordcount}" \
  -p "operationcount=${run_operationcount}" \
  -p "redis.timeout=${timeout}" \
  -p "redis.command_group=${command_group}" \
  -p "fieldcount=${fieldcount}" \
  -p "fieldlength=${fieldlength}" \
  -p "requestdistribution=uniform" \
  -threads ${threads}

sleep ${run_sleep_time}

Step 3: Test read throughput (Zipfian distribution)

./bin/ycsb run redis -s -P workloads/workloadc \
  -p "redis.host=${ip}" \
  -p "redis.port=${port}" \
  -p "recordcount=${recordcount}" \
  -p "operationcount=${run_operationcount}" \
  -p "redis.timeout=${timeout}" \
  -p "redis.command_group=${command_group}" \
  -p "fieldcount=${fieldcount}" \
  -p "fieldlength=${fieldlength}" \
  -p "requestdistribution=zipfian" \
  -threads ${threads}

sleep ${run_sleep_time}

Step 4: Test mixed read/update throughput

./bin/ycsb run redis -s -P workloads/workloada \
  -p "redis.host=${ip}" \
  -p "redis.port=${port}" \
  -p "recordcount=${recordcount}" \
  -p "operationcount=${run_operationcount}" \
  -p "redis.timeout=${timeout}" \
  -p "redis.command_group=${command_group}" \
  -p "fieldcount=${fieldcount}" \
  -p "fieldlength=${fieldlength}" \
  -p "requestdistribution=uniform" \
  -threads ${threads}

Script parameters

How to read these results

QPS and latency vary significantly between the two scenarios because of how ESSD-based instances handle data access:

• Scenario 1 (memory > data): Most reads are served from memory, so QPS is high and latency is low.

• Scenario 2 (data > memory): Most reads require disk access, so QPS drops and latency increases. Within this scenario, Zipfian-Read still benefits from hot-key caching and outperforms Uniform-Read significantly.

Expect significantly lower QPS in Scenario 2 compared to Scenario 1 for the same instance type. This is expected behavior, not a defect.

Scenario 1: Memory size larger than data volume

Memory:data ratio ≈ 7:1. Results reflect near-memory-speed performance.

Scenario 2: Data volume larger than memory size

Memory:data ratio ≈ 1:4. Most requests require disk access, so QPS is lower and latency is higher compared to Scenario 1.