warp versioned
Test mixed workload performance on versioned objects combining GET, PUT, DELETE, and STAT operations.
Synopsis
warp versioned [FLAGS]The versioned command benchmarks combined operation performance on versioned buckets. The command simulates real-world workloads with object versioning enabled by executing multiple operation types simultaneously. You can configure the distribution ratio of each operation type to match your versioned workload patterns.
warp versioned --host myaistor.example.com:9000 --access-key ACCESS_KEY --secret-key SECRET_KEYRun a basic versioned benchmark with default operation distribution. The command measures how the storage system handles varied concurrent operations with versioning enabled.
Flags
Command-specific flags
--objects
Default: 250
Number of objects to upload before starting the versioned operations benchmark. The command creates this many objects during the preparation phase. Use this flag to test versioned workload performance with different object pools.
The default is lower than the mixed command due to version creation overhead.
Example:
warp versioned --host myaistor.example.com:9000 --objects 500 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY--obj.size
Default: 10MiB
Size of each object created during the benchmark. The object size affects performance characteristics of GET and PUT operations. Use this flag to test versioned workloads with different object sizes.
Valid formats include numbers or values with KiB, MiB, or GiB suffixes (base 2 binary).
Example:
warp versioned --host myaistor.example.com:9000 --obj.size 50MiB --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY--get-distrib
Default: 45
Percentage of operations that should be GET requests. The distribution value determines how frequently GET operations occur in the versioned mix. Use this flag to adjust workload characteristics for read-heavy scenarios.
Example:
warp versioned --host myaistor.example.com:9000 --get-distrib 70 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY--stat-distrib
Default: 30
Percentage of operations that should be STAT requests. The distribution value determines how frequently STAT operations occur in the versioned mix. Use this flag to adjust workload characteristics for metadata-heavy scenarios.
Example:
warp versioned --host myaistor.example.com:9000 --stat-distrib 20 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY--put-distrib
Default: 15
Percentage of operations that should be PUT requests. The distribution value determines how frequently PUT operations create new versions. Use this flag to adjust workload characteristics for write-heavy scenarios.
Each PUT operation creates a new version of the object.
Example:
warp versioned --host myaistor.example.com:9000 --put-distrib 25 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY--delete-distrib
Default: 10
Percentage of operations that should be DELETE requests. The distribution value determines how frequently DELETE operations create delete markers. Use this flag to adjust workload characteristics for deletion-heavy scenarios.
Keep the delete distribution at or below the put distribution, or the test runs out of object versions to delete.
Example:
warp versioned --host myaistor.example.com:9000 --delete-distrib 15 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYShared flags
This command supports all common flags including connection, performance, object, upload, benchmark control, analysis, and monitoring flags.
Benchmark behavior
The versioned benchmark operates in two phases with versioning enabled on the bucket.
During the preparation phase, the command uploads the specified number of objects to the target bucket. The upload phase creates objects with the specified size to populate the initial object pool. Object names use random prefixes to distribute objects across the storage system. The bucket must have versioning enabled for the benchmark to function correctly.
During the versioned operations phase, the command executes operations according to the configured distribution. The benchmark randomly selects operation types based on the distribution percentages. GET operations retrieve existing object versions from the pool. STAT operations retrieve metadata for existing object versions. PUT operations create new versions of existing objects and add them to the pool. DELETE operations create delete markers for object versions.
The command measures throughput, latency, and error rates for each operation type independently. Versioned workload performance reveals how the storage system handles concurrent diverse operations with versioning. The distribution ratios simulate realistic application access patterns with version management.
Output
The versioned benchmark provides comprehensive metrics for all operation types with versioning.
The output includes separate statistics for each operation type. Operations per second displays the rate for GET, PUT, STAT, and DELETE operations individually. Throughput metrics show MB/s for GET and PUT operations. Latency percentiles show response times at p50, p90, p99, and p99.9 levels for each operation type.
The benchmark reports first-byte latency for GET operations. Error rates display counts and percentages of failed operations by type. Total operation counts show how many of each operation completed during the test.
Version-specific metrics reveal the impact of versioning on operation performance. Version creation rates show how quickly new versions are created through PUT operations. Delete marker statistics reveal deletion performance with versioning enabled.
Examples
Basic versioned workload
Test versioned operations with default distribution:
warp versioned --host myaistor.example.com:9000 --access-key ACCESS_KEY --secret-key SECRET_KEYThe command executes 45% GET, 30% STAT, 15% PUT, and 10% DELETE operations with versioning.
Read-heavy versioned workload
Test a read-heavy versioned workload pattern:
warp versioned --host myaistor.example.com:9000 --get-distrib 70 --stat-distrib 20 --put-distrib 5 --delete-distrib 5 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYThis simulates applications with predominantly read operations on versioned objects.
Write-heavy versioned workload
Test a write-heavy versioned workload pattern:
warp versioned --host myaistor.example.com:9000 --get-distrib 20 --stat-distrib 10 --put-distrib 40 --delete-distrib 30 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYThis simulates applications with significant version creation activity.
Balanced versioned workload
Test an evenly distributed versioned workload:
warp versioned --host myaistor.example.com:9000 --get-distrib 25 --stat-distrib 25 --put-distrib 25 --delete-distrib 25 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYThis tests system performance under balanced operation types with versioning.
Large object versioned workload
Test versioned operations with larger objects:
warp versioned --host myaistor.example.com:9000 --obj.size 100MiB --objects 100 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYLarger objects test bandwidth-intensive versioned workloads.
High concurrency versioned operations
Test concurrent versioned operations:
warp versioned --host myaistor.example.com:9000 --concurrent 50 --objects 500 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYThis tests how the system handles many simultaneous diverse versioned operations.
Extended versioned testing
Run a longer versioned workload test:
warp versioned --host myaistor.example.com:9000 --duration 30m --objects 300 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEYExtended tests reveal performance stability over time with versioned operations.