warp versioned

Test mixed workload performance on versioned objects combining GET, PUT, DELETE, and STAT operations.

Synopsis

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.

The delete distribution must be at least equal to the put distribution to maintain version stability.

Example:

warp versioned --host myaistor.example.com:9000 --delete-distrib 15 --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY

Shared 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_KEY

The 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_KEY

This 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_KEY

This 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_KEY

This 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_KEY

Larger 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_KEY

This 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_KEY

Extended tests reveal performance stability over time with versioned operations.