What are IOPS?

IOPS are expressing the performance a storage device can achieve with completing read and
write commands in a second. We will look at a simplified example for how many IOPS a disk
can deliver within the boundaries of physics. These are called the back-end IOPS. Simply put
how many IOPS can the disk(s) in the back-end deliver. Every disk in your storage system has a
maximum IOPS value that is based on a formula, namely:

IOPS = 1000ms / (Average Seek time in ms + Average Latency in ms)

Rotational speed is measured in revolutions per minute (RPM). How fast the disk
platters are rotating inside the disk.

Average Latency is the time taken for the platter to undergo half a disk rotation. Why
half? Well at any one time the data can be either a full disk rotation away from the head,
or it might already be right at it. The time taken for a half rotation therefore gives us the
average time it takes for the platter to spin round enough for the data to be retrieved. To
calculate the average latency take the RPM and use the following formula: Average
latency = ((60 seconds / RPM speed)/half rotation 2)*1000ms.

Average Seek time is the time in milliseconds (ms) it takes for the disks head to position
itself over the track being read or written. When the I/O request comes in for a particular
bit of data, the head will not be above the correct track on the disk. The arm will need to
move so that the head is directed over the correct track where it must then wait for the
platter spin to present the target data beneath it. As the data could potentially be anywhere
on the platter, the average seek time is time taken for the head to travel half way across
the disk. There are both read and write seek times; by taking the average of those two
values give you the average seek time.

Theoretical IOPS for Calculation Sizing

For disk (HDD and SSD) I normally use the numbers in the following table as a rule of thumb to
calculate raw backend random IOPS from disks. Raw? Yes RAW, because we dont factor in
caching/buffering in the whole chain (disk, controller, head, adapter, hypervisor, operating
system, application, workstation), RAID influence, interface connection, driver configurations,
queue depths, etc. But lets keep this simplified to have a workable model to calculate the IOPS
from the backend easily.

Averag
IOPS ~ IOPS range e
Disk RPM
Average Latenc
y (ms)
5.4K HDD 55 50-65 5,6
7.2K HDD 80 75-100 4,2
10K HDD 120 120-140 3,0
15K HDD 180 175-210 2,0
SSD (WI) 40000 65000-115000 0,1**
SSD (MU) 8500 7000-25000 0,1**
SSD (RI) 3000 2000-15000 0,1**
BSSD (ICE) 20000 5000-85000 0,1**

** Latency on SSD is not because the spinning of the disk (duhhh no mechanical
moving parts in here, latency on SSDs is on average 0.03ms!), but the network
chain between the processing and the SSD.

Front-End versus Back-End IOPS

Often you will hear that an application will need 2.400 IOPS and that it communicates with 64K
block size. Like for instance Microsoft SQL Server 2014 OLTP Log files. These are the so-called
Front-End IOPS, but to let that data land on the Back-end storage systems they generate Back-
End IOPS.

Size does matter!

Lets compare a storage system that stores the data with a block size of 128K and a storage
system with 4K blocks.

We will see that it will require 15 disks and 1.200 IOPS in the back-end when the storage system
can store with 128K blocks. If you store this same I/O stream on a storage system that utilizes
4K blocks you will need a whopping 38.400 IOPS. To back those incoming IOPS you will need
to run with 480x 7.2K NL-SAS disks!!!

Like most applications you can have different front-end IOPS and block sizes per workload, even
within one application. Microsoft SQL 2014 server is a good example that uses a different disk
access pattern as shown in the following table:
Info: Oracle DB default block size is 8K, and the Hadoop default block size is 64M.

Ok now we know that size does matter but why should you care? Most SQL Server performance
issues in (virtual) environments can be traced to improper storage configuration. SQL Server
workloads are generally I/O heavy, and a misconfigured storage subsystem can increase I/O
latency and significantly degrade performance of SQL Server. Running Microsoft SQL server on
VMware? Checkout this valuable resource about Architecting Microsoft SQL Server on VMware
vSphere