Calculating Back of Envelope Estimates for IOPS

I recently spent some time putting together a simple spreadsheet to help me estimate how many IOPS to expect from a given config.  I thought that I would share with the group.  Some of the key factors in the equation are pretty cut and dried, but others have to estimated.  So this equation will only give you an answer that is as good as your estimates.  This formula and blog is really designed to estimate random IOPS and doesn't talk about sequential. (Previous two sentences should be read as my disclaimer and please notice the use of the word estimate in the title and throughout the blog post).

I'm first going to explain the equation, and then I'll give it to you in short form with a few examples.

Reads / Writes and RAID types - A single read results in a single read operation, but a write results in multiple operations depending on the RAID type used.  The two mirroring RAIDs of 1 and 10 have a write cost of 2.  RAID 5 has a write cost of 4.  For this reason the equation is broken up into two halves for calculating the number of reads and the number of writes.  The weight given to reads and writes is based on an estimation of the read/write ratio of the workload (this is one of the estimates that you must come up with that makes a big difference in final number).

Disk Performance and Number of Disks - Each individual disk is capable of a given number of random I/O operations per second.  The better or faster a disk is, the more IOPS it can complete.  There are lots of sources around the web with estimates for 7200, 10K , 15K, and SSD disks.  I've always used the round number of 120 IOPS as an estimate for a 10K RPM disk for example.  The other factor here is the cache on the RAID controller or SAN processor or whatever it is called by the solution that you are using.  The size of the cache will effect the overall performance with larger caches generally allowing higher performance. Estimating the IOPS per disk is the other number that can cause a big difference in the final results that must be estimated.

So you multiply the number of disks in the RAID set by the estimate for IOPS per disk to get a total IOPS for the LUN / virtual disk / RAID group / whatever you want to call it.  You then multiply this by the percentage of reads for the read half of the equation.  For the write half you do the same, but you then have to apply the write penalty and divide by the RAID cost for the RAID type you are using.  I think about now is when you realize why RAID 5 performs so poorly in write intensive environments.

Here is the formula in a simple terms:

( (Num Disks * IOPS per Disk) * pct Reads) ) + ( ( (Num Disks * IOPS per Disk) * pct Writes) / RAID Cost)

Examples:

An example for an 8 x 10K RPM disk RAID 1/0 with 60 percent Reads and 40 percent Writes

( ( 8 * 125) * .60) + ((( 8 * 125) * .40) / 2) = 800 IOPS

same but change estimate of IOPS per disk to 150

( ( 8 * 150) * .60) + ((( 8 * 150) * .40) / 2) = 960 IOPS

And now change to RAID 5 with cost of 4:

( ( 8 * 150) * .60) + ((( 8 * 150) * .40) / 4) = 840 IOPS

And finally RAID 5 with 85% writes:

( ( 8 * 150) * .15) + ((( 8 * 150) * .85) / 4) = 435 IOPS

Special thanks to Scott Lowe for his excellent blog on essentially the same topic last year.