Skip to content

workload-profiles.md

Latest commit

 

History

History
91 lines (72 loc) · 3.97 KB

workload-profiles.md

File metadata and controls

91 lines (72 loc) · 3.97 KB
Raw

Single-file performance tests

V1 uses a deliberately small model: one YAML file is one complete runnable test. There are no imports, inheritance, overlays, catalogs, separate resource profiles, or command-line load overrides. To make a variant, copy a file, give it a new name and output directory, then edit it.

Built-in choices

fluss-testbed list
Use case File Recommendation
Primary Key capacity tests/ycsb-kv.yaml Default choice; hotspot, update/insert mix, and configurable record fields
Log append capacity tests/nexmark-log.yaml Person/Auction/Bid event mix with hot entities and delayed event time
Fluss-specific KV tests/fluss-iot-kv.yaml Sensor/device distribution adapted from the official Fluss benchmark

All generators are deterministic from the YAML seed; payloads are synthetic, not downloaded datasets. This is normal for storage benchmarks because the important properties are size, key popularity, operation mix, event mix, and repeatability. The models come from YCSB, Apache Beam Nexmark, and Apache Fluss Benchmarks. The latter two are adapted to Gateway HTTP/JSON; their native/Flink performance numbers are not directly comparable.

YAML structure

The top-level sections are intentionally fixed:

Section Defines
target Gateway and metrics URLs, cluster, exact candidate image identity
resources Required container names and CPU, memory, and PID limits
table Bucket count
workload One tagged generator: ycsb, nexmark, or fluss_iot
request Rows batched in each HTTP request
load Open-loop rate ladder, stage timing, concurrency, connections, stop policy
assertions Error/drop/latency/generator/OOM/memory safety limits
output Artifact directory and optional raw/metrics/Markdown outputs
cleanup Whether run-scoped Gateway objects are removed on success/failure

The YAML itself is the run manifest. The runner copies it into the artifact directory as test-spec.yaml and writes the normalized form as resolved-test.json.

Safe edit-and-run loop

mkdir -p local-tests
cp tests/ycsb-kv.yaml local-tests/my-kv-test.yaml
# Edit name, workload, rates, timing, resource limits, and output.directory.

fluss-testbed validate local-tests/my-kv-test.yaml
fluss-testbed plan local-tests/my-kv-test.yaml
fluss-testbed run local-tests/my-kv-test.yaml

validate is offline and strict. It rejects unknown keys, unsupported versions, non-increasing/zero rates, invalid proportions, empty resources, and unsafe duration or limit values. plan is also offline and reports the amount of work before a potentially expensive run.

Only run --artifact-dir <path> is accepted as an operational override. It changes where evidence is written but cannot silently alter the benchmark semantics.

Resource enforcement and reports

The checked-in topology and YAMLs use:

Component CPU Memory PID limit
Gateway 0.75 CPU 512 MiB 128
Coordinator 0.25 CPU 512 MiB 160
Tablet 0.75 CPU 1536 MiB 192
ZooKeeper 0.25 CPU 256 MiB 128
Total 2 CPU 2816 MiB —

Before creating test data, run verifies the running Gateway image ID and the configured architecture/revision. It then reads cpu.max, memory.max, and pids.max from every configured container. Each stage records effective CPU use relative to quota, memory current/peak/headroom, PID use, network deltas, and OOM state. A stage is unstable when any configured correctness, latency, generator, drop, or resource assertion fails.

The report declares the highest offered rate whose stage remained stable and the corresponding actual request/s and row/s. This is an observed point on the configured rate ladder, not a universal capacity claim.