Performance is a loaded term, and often means different things to different people. Gear6 is very focused on delivering the maximum performance to accelerate storage, and also to improve application servers by guaranteeing access to enough I/O Operations per Second so they can keep humming along.
When we discuss storage performance, we break it down into three categories:
I/O Operations per Second (IOPS): how many requests and responses can be processed in a second
Latency: how long does it take to respond to a single request
Throughput: what is the bandwidth (usually in Megabytes per second) of the traffic flow between the storage device and the application servers
It may seem simple enough, but the combination and balance between these characteristics is important in evaluating critical data center bottlenecks and solutions. Technically speaking, throughput and IOPS are directly related (they are computed from the same value), but the difference is in how people use the terms. People usually use IOPS when they are talking about how many small I/O operations a device can push through, and use throughput/bandwidth when they are talking about how well the device can saturate the network.
Let's take a closer look at latency. Dave Hitz from NetApp recently wrote a piece on Lies, Damned Lies, and Benchmark Results, where he added in the comments:
For I/O bound applications, storage latency is the key limiter to performance. If the storage can respond in 1ms, then you get 1000 responses per second to a single thread. If the storage responds in 2ms, then you get 500. The difference between 1ms and 2ms seems small, but it cuts the performance of your application in half.
I/O Operations per Second are equally important. I recently came across this piece on HP's website on Fast Storage:
"Organisations often forget about the need for fast storage, but immense calculations per second don't mean a thing if storage and input/output (I/O) can't keep up," says Kent Koeninger, product and technology marketing manager for HP's High-Performance Computing Division. "This has resulted in some very real problems for those seeking efficient, scalable and cost-effective high-performance computing."
Throughput is the third key ingredient, representing the amount of sustained bandwidth between a storage device and the clients it serves. Often throughput is touted as the key performance metric for a given solution, but it is critical to dig deeper into IOPS and latency particularly when dealing with applications that have lots of simultaneous requests, or lots of small files. In these cases, throughput alone might not be sufficient to solve big bottlenecks.
There has been a lot of discussion recently regarding clustered and parallel file systems, which are often great solutions for managing a large amount of capacity without hindering performance. These solutions focus on aggregating massive disk-based capacity and allowing high throughput to a single data store. These same solutions are not necessarily the best to deliver high IOPS or low latency. We wrote about this in Global Filesystems > Global Wait?. But the combination of a clustered file system and a scalable caching appliance can provide high IOPS, low latency, high throughput, and the ease of managing a single global namespace. Many Gear6 customers have found this to be an ideal solution.
Gear6 published a paper on solving rendering bottlenecks in animation for the Siggraph show a few weeks ago. We also presented a sampling of the performance of our G200 scalable caching appliance. Note that we present IOPS numbers, which exceed 300,000, and also latency numbers (measured in microseconds). Even at the 300,000 mark, latency is 0.25 milliseconds.



"Technically speaking, throughput and IOPS are directly related (they are computed from the same value), but the difference is in how people use the terms."
Actually, the difference is that the MB/s pushed by a database is minuscule compared to a backup server or graphics file server, but these high bandwidth applications do very few, but very large sequential reads or writes. The IOs per second stat is usually directed at databases that do a large number of small, random reads and writes.
I agree with much you have written, however it's important to differentiate workloads.
Another thing- latency is a contributing factor to IOs per second, not a measurement in its own right. I don't know of any applications that can only perform one read or write at a time, so latency might drive the application performance up or down, but it won't be linear as Dave Hitz seems to be claiming.
Posted by: Open Systems Guy | September 13, 2007 at 12:47 PM
Open Systems Guy,
Thanks for the clarification. We try whenever possible to take a workload-driven view.
Stay tuned for an upcoming post on "What is an IOP?" As this term gets more attention with industry recognition of performance needs, we think it deserves more explanation.
Posted by: Gary O. | September 24, 2007 at 06:02 PM
Hi,
I am still not clear about the way IOPS and Throughput has been differentiated.
Can anyone plz help me in understanding this clearly.
Posted by: Siddaraju | January 02, 2008 at 06:37 AM
Siddaraju,
Another way to think about it:
Throughput is similar to the number of lanes on a highway.
IOPS is similar to the speed of a single car.
You really need both to get a lot of people (or information) moving back and forth. And having a wide highway won't help if all the cars only go a few miles per hour.
Hope this helps. -Gary
Posted by: Gary O. | January 02, 2008 at 10:55 AM