Warp Benchmarks

MinIO Warp is a single-binary S3 performance tool for measuring GET, PUT, and mixed workload performance. Use it for quick bucket-wide single-operation throughput numbers when you don't need COSBench's stage machinery or httpbench's per-worker isolation.

For when to pick Warp over COSBench or httpbench, see Choosing a Benchmark Tool. For reference throughput from a 6-node Warp run, see Reference Performance Baselines.

Warp is incompatible with redirect-mode clusters. Warp does not follow HTTP 307, and its --list-existing flag enumerates the entire bucket — so on a redirect-enabled 6-worker cluster, 5⁄6 of warp's GET requests hit 307 and fail. Options:

1. Disable alluxio.worker.s3.redirect.enabled cluster-wide before running warp (requires worker restart), or

2. Use httpbench instead — it follows 307 transparently and can target a single worker.

For which clients are affected by redirect behavior, see Deployment Patterns.

Prerequisites

• Alluxio worker reachable from the warp host on the S3 API port (default 29998).

• Pre-loaded data for GET tests: use bin/alluxio job load --path /path --submit and verify with bin/alluxio fs check-cached /path. Or create data via warp put first, as shown below.

• Redirect disabled (alluxio.worker.s3.redirect.enabled=false, the default) — see the warning above.

Installation

# Install via Go
go install github.com/minio/warp@latest

# Or download a binary release from GitHub

Usage

Scenario: PUT Throughput (Write)

Warp PUT compatibility: Warp uses chunked SHA-256 payload signing by default, which Alluxio S3 does not support. This causes write failures and InvalidTag errors. Add --disable-sha256-payload=true to all warp put commands.

# Upload 10KB small files
warp put --host=<ALLUXIO_WORKER_IP>:29998 \
         --bucket=warp-benchmark-bucket \
         --duration=60s \
         --obj.size=10KiB \
         --concurrent=16 \
         --disable-sha256-payload=true

# Upload 1GB large files
warp put --host=<ALLUXIO_WORKER_IP>:29998 \
         --bucket=warp-benchmark-bucket \
         --region=us-east-1 \
         --obj.size=1GiB \
         --part.size=32MiB \
         --insecure \
         --concurrent=16 \
         --duration=60s \
         --disable-http-keepalive=false \
         --disable-sha256-payload=true \
         --noclear

Scenario: GET Throughput (Read)

# Ensure data exists first (either via warp put above, or pre-loaded directly to S3)
warp get --host=<ALLUXIO_WORKER_IP>:29998 \
         --bucket=warp-benchmark-bucket \
         --concurrent=16 \
         --obj.size=100KiB \
         --duration=1m \
         --prefix=prefix/ \
         --list-existing

Scenario: Multi-Node GET (Distributed Read)

When running warp across multiple nodes, use --syncstart to ensure all nodes begin at the same wall-clock time. Without it, nodes that start earlier will run uncontested for a few seconds, inflating their individual numbers and making aggregate throughput non-comparable across runs.

# Run this on every warp node simultaneously, with the same --syncstart time
warp get --host=<ALLUXIO_WORKER_IP>:29998 \
         --bucket=warp-benchmark-bucket \
         --concurrent=16 \
         --obj.size=100KiB \
         --duration=5m \
         --prefix=prefix/ \
         --list-existing \
         --syncstart=14:30  # HH:MM in 24h local time — set to ~60s from now

Each node writes a local .json.zst result file. Merge them for aggregate stats:

warp merge node1.json.zst node2.json.zst node3.json.zst

Troubleshooting

• Warp PUT fails or returns InvalidTag — Warp's default chunked SHA-256 payload signing is not supported by Alluxio S3. Add --disable-sha256-payload=true to all warp put commands.

• Warp GET returns errors or 307 — Warp does not follow HTTP 307 redirects. Ensure alluxio.worker.s3.redirect.enabled=false (the default), or switch to httpbench.

For cross-tool troubleshooting (cache-hit verification, network bottlenecks, kernel tuning), see Performance Tuning and Troubleshooting on the hub page.

See Also

• S3 API Benchmarks — overview, reference baselines, tool selection, cross-tool troubleshooting

• COSBench Benchmarks — for complex multi-stage workloads

• httpbench Benchmarks — for redirect-mode clusters or per-worker measurement

• S3 API Setup and Configuration — deployment patterns, endpoint setup, load balancer configuration