-1
$\begingroup$

I was reading about latency and IOPS, and I understood what they mean and their significance in the storage world. But what I do not understand (many places it is mentioned) is that how can the numbers actually conflict with each other when an example is given.

In this explanation, the author states one of the examples saying..

Mr. Customer, our box can do a quarter million random 4K IOPS – and not from cache!”

…at 50ms latency.

Here, if the latency in 50ms then 4K IO's should take 200s. And if really 4K IO's is being completed in 1 sec, then should'nt the average latency be 4ms?

Can someone please explain what I am missing here.

$\endgroup$
3
  • 3
    $\begingroup$ "4K IOPS" simply refers to certain kinds of IOPS. It does not mean "4000 operations". It means e.g. "operations in which we read 4KB of data from the disk". Therefore multiplying 50ms by 4000 really makes no sense (I guess this is how you got the number "200s"). The number of operations per second in the quote is "a quarter million", i.e. 250 000, not 4000. $\endgroup$ Sep 11 '16 at 20:55
  • 2
    $\begingroup$ Anyhow, I guess there is some confusion about the definitions of throughput (here "IOPS") and latency. Reading e.g. some of these answers probably helps to see why throughput and latency are not directly related to each other: quora.com/What-is-the-difference-between-latency-and-throughput $\endgroup$ Sep 11 '16 at 21:05
  • 2
    $\begingroup$ Each 4KB I/O operation has a latency of 50 ms. As long as they are independent, the system can perform 250,000 such operations per second. For example, the first I/O operation could complete after 50 ms, the second might complete after 50.004 ms, the third after 50.008 ms, etc. $\endgroup$ Sep 12 '16 at 0:23
0
$\begingroup$

As an example, you might be able to sort requests so that they can be handled in an optimal order. That's mostly relevant for hard drive access, where the time for one access depends strongly on where the previous access was. So you don't respond to a request as quickly as possible, but you wait until you have a few request going to nearby locations on your drive, doing something else in between, and then the total time for n requests is much faster than the average time for a single request would be.

It's like the postman in the post office who first sorts his letters before he starts delivering them.

By grouping more requests together, you can handle them more efficiently, so throughput goes up, but on the other hand you wait longer until you start handling each request, so latency goes up as well. And of course you can group fewer requests together for the opposite effect.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.