Storage IOPS, throughput and latency

What it means

A storage rate needs its workload context. An IOPS figure becomes a byte rate only when you know how much data each operation moves. This example uses a fixed operation size and binary units throughout, allowing you to isolate that relationship without pretending to benchmark a device. Its result answers “What byte rate do these inputs imply?” rather than “How fast is my storage?”

Try it

Example — local calculation, not a storage test. Change KiB per operation from 4 to 8, then inspect the computed result and its explanation. Select Compare with baseline to place the current outcome alongside the starting result. No storage change or external request is performed.

The starting result is 39.1 MiB/s. 10000 operations each moving 4 KiB imply 40000 KiB/s; latency and queue behavior are independent constraints. Increasing only the operation size to 8 KiB doubles the implied byte rate because each of the same 10000 operations transfers twice as much data.

Keep I/O operations per second at 10000. Only KiB per operation changes. The initial example remains readable without JavaScript; interactive controls require JavaScript.

Reset restores I/O operations per second to 10000 and KiB per operation to 4, clears input errors, and removes the comparison. It preserves your independent choices to open or close FAQ answers and About this model.

How it works

IOPS counts operations, not their size. Multiplying the count by the bytes moved in each operation produces the total bytes moved per second. With this example’s units:

IOPS × KiB per operation = KiB/s

KiB/s ÷ 1024 = MiB/s

That relationship explains the conversion, but it does not establish capacity. A system must accommodate both the operation rate and the resulting byte rate under the applicable conditions. Increasing operation size raises the byte rate required to keep IOPS unchanged; a throughput ceiling may become restrictive before the operation-rate ceiling does.

Latency asks a different question: how long does an operation take? The conversion contains no request-delay or queue-depth input, so it cannot calculate those outcomes. Holding IOPS constant in the example does not show that real queueing or latency would remain unchanged when operation size increases.

Worked example

This is a synthetic baseline, not a captured production observation.

The intermediate rate is 10000 × 4 = 40000 KiB/s. Dividing by 1,024 gives 39.0625 MiB/s, displayed as 39.1 MiB/s. The rounding affects the displayed number, not the assumed workload.

As a unit cross-check, 256 operations per second at 4 KiB per operation yield 1024 KiB/s, or 1.0 MiB/s. Both calculations establish a unit relationship, not observed storage capacity.

What changes when the condition changes

Change KiB per operation from 4 to 8 while keeping I/O operations per second at 10000. The result is 78.1 MiB/s: 10000 operations each moving 8 KiB imply 80000 KiB/s. The unrounded rate is 78.125 MiB/s.

Each operation now moves twice as much data, so the same operation count implies twice the byte rate. This is not evidence that changing a real workload will double its throughput: the example holds IOPS constant rather than predicting it. If a real system reaches a fixed throughput ceiling, larger operations can instead reduce the operation rate that fits beneath that ceiling. At the same byte-rate ceiling, doubling operation size halves the maximum IOPS allowed by that ceiling; other constraints may lower it further.

In practice

Start with existing read-only measurements you are authorized to view. Record operation size, units, read/write mix, access pattern, queue depth, and observation interval alongside IOPS and throughput. Compare like conditions; otherwise, a difference may describe different workloads rather than different storage capabilities.

For a workload dominated by many small operations, the operation-rate requirement may be the important constraint. For larger transfers, the required byte rate may reach a throughput ceiling first. For a response-time problem, inspect request-delay measurements, including the slower end of the distribution. The conversion helps relate the first two requirements; it cannot decide the third.

When using provider documentation, check the conditions for your exact storage product and configuration. The Amazon EBS I/O characteristics and gp3 performance sections listed in Sources illustrate separate IOPS and throughput constraints; they are not universal device benchmarks.

STOP before treating a converted rate as a capacity verdict if the applicable limits or workload conditions are missing. Collect that evidence first. Do not change provisioning or run a production load test solely on the strength of this calculation; this page does not provide a change or benchmarking procedure.

Limits and unknowns

The supported input ranges are 1–1000000 I/O operations per second and 1–1024 KiB per operation. Empty, nonnumeric, or out-of-range input is invalid: the calculated outcome is removed, and comparison is unavailable until you correct the input or use Reset. An earlier valid result does not apply to the invalid entry.

For valid inputs, the model calculates a byte rate, not a device verdict. Whether a real system can sustain that rate remains unknown without applicable capacity limits and workload evidence. Missing latency evidence also remains missing; a successful calculation does not establish low latency.

The calculation assumes a fixed operation size and sustained IOPS. It ignores overhead, queueing, and tail latency, and it does not access a real machine, account, storage device, filesystem, or service.

What to carry forward

Use operation size to connect IOPS with throughput, then check capacity and latency separately. If the implied byte rate exceeds an applicable throughput ceiling, the assumed sustained IOPS rate cannot hold at that operation size. If the arithmetic fits within the documented limits, that still leaves actual request delays unproved.