Skip to main content
This runbook turns the ycsb-endpoint config-connect seam into a cloud product evaluation: throughput + tail latency from the recognized YCSB tool, plus the price/performance composite, against a managed Redis-compatible service you operate.
The connect chain (target → adapter → suite → evaluator) is covered by this repo’s CI (unit + mock). The live steps below need your managed service and the upstream YCSB tool — clousight-bench never provisions the service for you on this path, so nothing here creates cloud spend by surprise.

​
0. What you need

  • A managed Redis-compatible instance (Aliyun Tair/Redis, AWS ElastiCache, …) reachable from the driver machine (VPC/allowlist configured).
  • The YCSB launcher (Java ≥ 11): YCSB releases — put ycsb on PATH or set YCSB_HOME.
  • pip install clousight-bench.

​
1. Where to run the driver (read this)

Numbers include the network between driver and service. For comparable results, run the driver in the same region/VPC as the service (an ECS/EC2 box), not your laptop over the public internet. Record where you ran it — the environment fingerprint keeps cross-machine numbers from pooling anyway, but be kind to your future self.

​
2. Connect profile

Start from the committed example (examples/cloud-connect/aliyun-redis.yaml / aws-elasticache.yaml):

​
3. Preflight, then run

csbench doctor now probes for real: a Redis-protocol PING (auth never sent; -NOAUTH still proves a live service) plus YCSB launcher + Java ≥ 11 checks. A wrong address, a closed allowlist or a missing/old tool surfaces here with a remediation hint — not as a mid-run stack trace. The same checks gate csbench run at its PREFLIGHT stage.
You get ycsb.throughput_ops, ycsb.read_p99_us, ycsb.update_p99_us, … — environmental measurements from the unmodified upstream tool. Only runs sharing a benchmark and environment fingerprint pool.

​
4. Price/performance

Map the instance’s price to the headline metric via the pricing feed (see TPC-H price/QphH for the mechanism):
CLOUSIGHT_PRICING_DATA=feed.json csbench run … adds extensions.pricing.price_performance[] — $ per (ops/sec), unaudited, from your own price input. It can never change the verdict.

​
5. Reliability under disruption (R5)

The harness owns the driver-side network path, so it can disrupt it honestly — no server-side fault injection against a managed service:
The measured run phase routes through a local TCP relay toward your endpoint; at at_s the harness cuts every active connection (reset) or holds forwarding (stall). Disruption requires the redis binding and a target endpoint — with any other binding the run fails loudly rather than run a clean benchmark under a disruption-labeled dataset. What lands in the record is evidence, never invention: ycsb.error_rate / ycsb.ops_failed come from YCSB’s own Return= counts, ycsb.completed_under_disruption appears only when the disruption actually fired, and the trajectory carries a disruption span at the measured firing time (for stall, the gate-enforced window, clamped to run end). A different disruption plan is a different benchmark (folded into the dataset digest).

​
6. Honest caveats

  • YCSB’s Redis binding is single-node oriented; cluster-mode services need the cluster client flag upstream — validate before comparing across services.
  • Managed-service list prices change; record source/date in your feed.
  • Compare same workload, same record/operation counts, same region locality only — the fingerprints enforce the first two, you enforce the third.