NVIDIA/warp-minio

NVIDIA/warp-minio

Description: S3 benchmarking tool

License: AGPL-3.0

Stars: 2

Forks: 0

Open issues: 0

Created: 2026-05-20T20:08:43Z

Pushed: 2026-05-27T17:40:00Z

Default branch: nv-main-oss

Fork: yes

Parent repository: minio/warp

Archived: no

README: !warp

S3 benchmarking tool.

Download

From binary

Download Binary Releases for various platforms.

Build with source

Warp requires minimum Go go1.21, please ensure you have compatible version for this build.

You can follow easy step below to build project

• Clone project

λ git clone https://github.com/minio/warp.git

• Change directory and build

λ cd warp && go build

• To run a test, please run

λ ./warp [options]

Configuration

Warp can be configured either using commandline parameters or environment variables. The S3 server to use can be specified on the commandline using --host, --access-key, --secret-key and optionally --tls and --region to specify TLS and a custom region.

It is also possible to set the same parameters using the WARP_HOST, WARP_ACCESS_KEY, WARP_SECRET_KEY, WARP_REGION and WARP_TLS environment variables.

The credentials must be able to create, delete and list buckets and upload files and perform the operation requested.

By default operations are performed on a bucket called warp-benchmark-bucket. This can be changed using the --bucket parameter.

> [!WARNING] > Note the bucket will be *completely wiped* before and after each run, so it should not contain any data.

If you are running TLS, you can enable server-side-encryption of objects using --encrypt. A random key will be generated and used for objects. To use SSE-S3 encryption use the --sse-s3-encrypt flag.

If your server is incompatible with AWS v4 signatures the older v2 signatures can be used with --signature=S3V2.

Usage

λ warp command [options]

Example running a mixed type benchmark against 8 servers named s3-server-1 to s3-server-8 on port 9000 with the provided keys:

λ warp mixed --host=s3-server{1...8}:9000 --access-key=minio --secret-key=minio123 --autoterm

This will run the benchmark for up to 5 minutes and print the results.

YAML configuration

As an alternative configuration option you can use an on-disk YAML configuration file.

See yml-samples for a collection of configuration files for each benchmark type.

To run a benchmark use λ warp run .

Values can be injected from the commandline using one or multiple -var VarName=Value. These values can be referenced inside YAML files with {{.VarName}}. Go text templates are used for this.

Benchmarks

All benchmarks operate concurrently. By default, 20 operations will run concurrently. This can however also be tweaked using the --concurrent parameter.

Iceberg REST Catalog Benchmarks

Warp includes benchmarks for Apache Iceberg REST catalog operations. These test catalog metadata performance including namespace, table, and view operations.

Available commands:

• warp iceberg catalog-read - Catalog read operations
• warp iceberg catalog-commits - Commit generation via property updates
• warp iceberg catalog-mixed - Mixed read/write workload
• warp iceberg write - Parquet file upload and Iceberg table commit

Supports MinIO AIStor Tables and Apache Polaris catalogs.

See [README_TABLES.md](README_TABLES.md) for detailed documentation.

Tweaking concurrency can have an impact on performance, especially if latency to the server is tested. Most benchmarks will also use different prefixes for each "thread" running.

By default all benchmarks save all request details to a file named warp-operation-yyyy-mm-dd[hhmmss]-xxxx.csv.zst. A custom file name can be specified using the --benchdata parameter. The raw data is zstandard compressed CSV data.

Multiple Hosts

Multiple S3 hosts can be specified as comma-separated values, for instance --host=10.0.0.1:9000,10.0.0.2:9000 will switch between the specified servers.

Alternatively numerical ranges can be specified using --host=10.0.0.{1...10}:9000 which will add 10.0.0.1 through 10.0.0.10. This syntax can be used for any part of the host name and port.

A file with newline separated hosts can also be specified using file: prefix and a file name. For distributed tests the file will be read locally and sent to each client.

By default a host is chosen between the hosts that have the least number of requests running and with the longest time since the last request finished. This will ensure that in cases where hosts operate at different speeds that the fastest servers will get the most requests. It is possible to choose a simple round-robin algorithm by using the --host-select=roundrobin parameter. If there is only one host this parameter has no effect.

When benchmarks are done per host averages will be printed out. For further details, the --analyze.v parameter can also be used.

Distributed Benchmarking

!distributed

It is possible to coordinate several warp instances automatically. This can be useful for testing performance of a cluster from several clients at once.

For reliable benchmarks, clients should have synchronized clocks. Warp checks whether clocks are within one second of the server, but ideally, clocks should be synchronized with NTP or a similar service.

To use Kubernetes see Running warp on kubernetes.

Client Setup

WARNING: Never run warp clients on a publicly exposed port. Clients have the potential to DDOS any service.

Clients are started with

λ warp client [listenaddress:port]

warp client Only accepts an optional host/ip to listen on, but otherwise no specific parameters. By default warp will listen on 127.0.0.1:7761.

Only one server can be connected at…