When you are looking for enterprise storage, performance is what you really care about. Reliability is important, redundancy is important, compatibility is important. There are a lot of things are important, but nothing is as important as performance. The only reason enterprise storage exists is to house data and then to deliver that data to applications as quickly as possible.
We can all agree that performance is the most significant criteria when customers are evaluating and selecting all flash storage, and it is, in fact, the main reason companies are moving from hard disks to flash. So you would think that if performance is that important in selecting storage, then at the very least we should all be able to agree on how to measure performance.
So how do you measure speed? Well, if you are in a racecar you can measure speed with a speedometer as either miles per hour (mph) or kilometers per hour (kph). Still, that does not give you a real measure of how a car will perform in a race. What you need is a true definition of performance, such as how speed is measured which is a function of distance over time.
"IOPS numbers by themselves are meaningless and should be treated as such. Without additional metrics such as latency, read vs write % and I/O size (to name a few), an IOPS number is useless.
— "An Explanation of IOPS and Latency" by Dimitris Krekoukias, RecoveryMonkey.org
In business, we are all in a race to win. It is a race to win customers, to deliver products first to market, to process transactions faster, or whatever it is that drives your company's success. To win in this race, success is not just about achieving great results at a given moment, it is about delivering those great results consistently, over time.
In racing, whatever top speed a given car hits at a particular moment is not really relevant. What matters for that car is how it performed over the entire distance of the race. The same is true for storage. Often we see arrays that list their IOPS, which may just be a peak number that was achieved at a point in time, as the performance metric that they want to be judged by. Like the speed at a given moment for our racecar that is not really a true measure. For the measurement of IOPS to be truly useful, we need to look at it in the context of latency.
Into the Pit
Let's go back to our race analogy. In races there are times when every car has to make a pit stop. In Formula 1 racing there is a speed limit of 80 kph in the pit area. So while a car may be going 80 kph when it enters and leaves the pit, the car's average speed over time will actually be much lower. When the car is being refueled, getting new tires, and whatever else needs to be done, then it is not moving. That impacts its total time. If the car is in the pit too long, it can lose the race regardless of its top speed.
The speed of the car going into and out of the pit is the same kind of measurement as IOPS. The time in the pit, that is latency.
It's the same for enterprise storage. The measurement of IOPS, the speed of data going into and out of the interface ports, is good to know but it is only relevant in terms of overall system latency. How much time does it take the array to process the data once the read/write request is received?
That is why the important metric is not simply IOPS, but IOPS at latency. The more I/Os an array must manage, the bigger the impact on latency. It makes sense that the more I/Os that we ask an array to perform at a given time (that is, the more I/Os per second), the longer it will take that array to process those tasks. So the question becomes, if my application requires 50,000 IOPS, what will the latency be from a given array? What will the latency be at 100,000 IOPS? At 1 million IOPS?
We have seen some vendors quote 500,000 or even a million IOPS, but then find out that this is at 2-5 ms of latency, and sometimes longer. Performance like that should be totally unacceptable for flash storage. Enterprise customers require both high throughput and consistent low latency.
Why I Agree With Dimitris Krekoukias of RecoveryMonkey.org
This is why in an explanation on IOPS and latency, Dimitris Krekoukias writes, "IOPS numbers by themselves are meaningless and should be treated as such. Without additional metrics such as latency, read vs write % and I/O size (to name a few), an IOPS number is useless."
"High sustained latency in a mission-critical app can have a nasty compounding effect – A delay in the DB...and the company could well lose thousands of customers and millions of dollars while the delay is happening. Some companies could also face penalties if they cannot meet certain SLAs."
Will You Win the Storage Performance Race?
When you look at many all flash arrays, you will often see IOPS listed, but not latency. Why is that? Perhaps, they can reach a high I/O number, though often under ideal conditions that will never happen in the real world. You must ask the real-world question of what is the latency required to achieve this high I/O number? Maybe, they state what the minimum latency is (the lowest latency they could achieve under unrealistic tests), but at what overall throughput? We have seen some vendors quote 500,000 or even a million IOPS, but then find out that this is at 2-5 ms of latency, and sometimes longer.
Performance like that should be totally unacceptable for flash storage. Enterprise customers require both high throughput and consistent low latency. That is why Violin publishes numbers with both IOPS and latency, because if you are buying a racecar, you want to know you are getting one that will put you in the winner's circle.
Want to Drive a Race Car?
Let's shift gears for a moment. Click here and register for your chance to win a High Performance Racing and Driving class at a Skip Barber Racing School or you can choose from other prizes to help you indulge your inner adrenaline junkie.
I hope you will join Violin Systems's CEO, Kevin DeNuccio, next week and find out how all flash storage latency can create compelling ROI and how latency can have an incredibly powerful impact on your business.
Thank you for your registering. A link to the webcast will be provided via email on the day of the event.
Violin Systems reserves the right to refuse access to the webcast.