What Is IOPS?

What Is IOPS?

IOPS stands for input/output operations per second. It counts the read and write operations a storage device completes each second. 

The count ignores how much data moved, which is where throughput comes in. Ten thousand operations might carry 40 MB or 2.5 GB, depending on each one's size.

Most vendors quote read and write IOPS separately. The write figure is usually the lower one, because flash storage has to erase a block before it rewrites one.

You'll also see random and sequential figures split apart. Random IOPS is the harder number and the more honest one (real workloads rarely read a disk in neat order).

A high IOPS figure means the device handles plenty of small requests at once. It doesn't promise they come back quickly, which is a separate measurement.

How Do You Calculate IOPS and Throughput?

Throughput equals IOPS multiplied by the average size of each operation. Block size is what turns an operation count into a byte count.

Run it backwards to get IOPS, by dividing throughput by the average block size.

The table below runs that calculation across three workloads.

The first two rows run an identical number of operations. The second moves four times the data. Each operation carries four times the bytes.

Row three does a twelfth of the operations and still moves the most data. Block size drives that, and the operation count barely enters into it.

Why Does RAID Change the IOPS You Actually Get?

Disks in a RAID set don't deliver their combined raw IOPS to the application. Every write turns into several physical operations, and storage people call that multiplier the write penalty.

Reads escape the penalty entirely. Writes pay it every time (which is why a write-heavy workload needs far more spindles than the raw arithmetic suggests).

Work an example through it. Say a workload needs 1,000 IOPS on RAID 5, running 70 percent reads.

The 700 reads cost 700 operations, which is the easy half. Writes are where it gets expensive.

Those 300 writes carry a penalty of four each, so they cost 1,200 operations on their own. Add the two together and the disks underneath have to supply 1,900 raw IOPS to deliver the 1,000 anyone actually asked for.

Run that same workload on RAID 10 and the requirement falls to 1,300. The gap between those two numbers usually settles the RAID argument, long before anyone gets to usable capacity.

IOPS vs Throughput: Which One Should You Watch?

The workload decides which number to care about. Small scattered requests stress the operation count. Big sequential transfers stress the bytes.

Any vendor quoting one of these without the block size has told you little. Half a million IOPS at 512 bytes and half a million at 32 KB describe completely different hardware at completely different prices.

What Counts as a Good IOPS Figure?

Device class sets the range, and the gaps run to orders of magnitude.

Cloud storage plays by different rules, since the ceiling comes from the provider instead of the hardware. An AWS gp3 volume starts at a 3,000 IOPS baseline with 125 MB/s of throughput.

That's why 3,000 turns up in so many sizing questions (people are often quoting their cloud default back without realizing it).

No table answers this one for you. A good figure covers your own peak with headroom left over, and peak means the login storm or the month-end batch run. Measuring during a quiet spell gives you a number that flatters the storage and helps nobody.

How Do You Measure IOPS?

Every platform exposes the read and write counts, and the commands below pull them.

Measure during the busy period, never after hours. An average across a full day flattens the peak that actually sizes the storage.

Benchmark numbers only mean something at the block size your workload actually uses. Run a 4 KB random test and a 1 MB sequential test on one drive and the results can differ by a factor of fifty. An unlabeled benchmark figure is close to useless.

How Does Latency Affect IOPS and Throughput?

Latency measures how long one operation waits before it finishes, in milliseconds or microseconds. A device can post a spectacular IOPS figure and still feel slow to the people using it. Every one of those operations queued up first.

Queue depth ties the three together. Push more concurrent requests at a device and IOPS climbs, right up until the queue saturates. After that, p99 latency rises while IOPS just flattens out.

The point where latency starts climbing is the figure worth finding. A benchmark reporting IOPS without the latency it was measured at hides exactly that number, and vendors know it.

The same three metrics appear on the network side in different units. There, latency, bandwidth and throughput trade against each other in much the same way.

Which Storage Metrics Should You Monitor Together?

Chart IOPS, throughput in MB/s and average latency together. Read alone, any of the three can look healthy while the workload suffers.

Average block size belongs on that chart too. A shift in block size changes what good looks like for the other two.

Queue length belongs there as well. It's the early warning the other three won't give you, and a queue that grows while IOPS stays flat means the device already saturated.

So an IT storage capacity review starts with the request mix. The device spec comes second, and storage resource monitoring is where that mix gets measured.