Specialized tests
These tests can help evaluate particular capabilities rather than general performance.
| Test type | Use for |
|---|---|
| Multipart operations | Objects larger than 64MB |
| Versioning | Systems that maintain object history |
| Object retention | Compliance or immutability requirements |
| Distributed benchmarking | High-capacity storage systems |
| Long-running stability tests | Production deployment validation |
| Performance comparison | Configuration changes or upgrades |
Multipart operations
Multipart tests evaluate performance when transferring very large objects (>64MB) using parallel streams.
Use multipart-put for upload testing and multipart for download testing.
Each object has --parts parts of --part.size each.
multipart-put runs --concurrent uploads at once and sends up to --part.concurrent parts in parallel for each upload.
# Test large file uploads with parallel parts
warp multipart-put --parts 50 --part.size 100MiB --part.concurrent 10 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Test parallel part downloads
warp multipart --parts 500 --part.size 10MiB --concurrent 20 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Test maximum upload parallelism
warp multipart-put --parts 100 --part.size 100MiB --part.concurrent 50 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYMonitor part-level concurrency to understand how many parallel streams the storage system handles efficiently. Too many parallel streams risks overwhelming the system without improving throughput.
For the S3 operations used by these tests and additional compatibility notes, see the S3 compatibility and required operations section.
Versioning
Versioning tests evaluate performance when the storage system maintains multiple versions of objects.
Each PUT operation creates a new version rather than replacing the existing object.
Versioning adds overhead because the storage system tracks multiple object versions.
# Test a write-heavy versioned workload
warp versioned --objects 100 --obj.size 1MiB --put-distrib 40 --delete-distrib 40 --get-distrib 10 --stat-distrib 10 --concurrent 20 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Test a read-heavy versioned workload
warp versioned --objects 50 --obj.size 10MiB --get-distrib 60 --stat-distrib 20 --put-distrib 10 --delete-distrib 10 --concurrent 30 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYSee MinIO-specific features for notes about features that require MinIO servers.
Object retention
Retention tests measure how fast the storage system sets object lock retention.
The test uploads --objects objects with --versions versions each.
It then sets GOVERNANCE mode retention on random object versions until the test ends.
# Test retention on the default object set
warp retention --duration 1m --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Test retention on fewer objects with more versions
warp retention --objects 2500 --versions 10 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYRetention features typically add minimal performance overhead. The storage system primarily enforces deletion restrictions rather than affecting upload or download performance.
Distributed benchmarking
Distributed benchmarking coordinates multiple client machines to generate higher aggregate loads than a single machine can produce. Use this approach when you need to exceed single-client network or CPU limits.
For detailed information about architecture, setup, deployment strategies, and best practices for distributed benchmarking, see the Distributed benchmarking documentation.
Long-running stability tests
Stability tests run for extended periods to identify performance degradation or resource leaks. These tests verify that storage systems maintain consistent performance under sustained load.
Short tests (under 10 minutes) measure peak performance. Long tests (hours or days) reveal stability issues that only appear during extended operation.
# 24-hour stability test
warp mixed --duration 24h --concurrent 50 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYUse auto-termination to stop tests automatically when performance stabilizes to a variation of no more than 7.5% different for 7 of the last 25 samples. This saves time while ensuring tests run long enough to produce valid results.
# Run until performance stabilizes
warp mixed --autoterm --concurrent 50 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYFor details on how Warp determines stability or how to configure what is considered stable, see the GitHub readme.
Performance comparison
Warp includes a comparison tool that can analyze data from previously saved tests and identify differences between them. This approach helps evaluate configuration changes or system upgrades. Run multiple iterations to account for performance variability.
# Test configuration A
warp mixed --duration 30m --benchdata config-a --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Test configuration B
warp mixed --duration 30m --benchdata config-b --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY
# Compare results
warp cmp config-a.json.zst config-b.json.zstTo limit the results to just the test type provided, use warp analyze with the --analyze.v flag.
Comparison testing helps make informed decisions about hardware, configuration, or deployment options.
Additional available tests
Warp includes additional specialized tests for other uncommon use cases. For complete documentation on these tests, refer to the Warp repository README.
| Test | Purpose |
|---|---|
| ZIP | MinIO s3zip extension for archive access |
| Snowball | Bulk data import via TAR archives |
| Fanout | Single-to-multiple object replication |
| Append benchmark | S3 Express One Zone append operations |