Monday, July 4, 2016

Measuring IOPS part 4: binding IOMETER results to DISKSPD results

In the previous post we have seen that Diskspd can provide us with a quick information on MB/s and I/O per second (IOPS), as well as the average latency.
For the moment we have no idea if the 39k IOPS measured in the first sequential read test or the 710 total IOPS measured in the last random read and write test are good or bad result compared to the workload I have generated. The only thing that we have found for sure is that latency decreases when we use small IOs instead of large IOs. But we still don’t know if a latency of 5 ms, such the one measured in the last run, is a fancy value or not.
We need to investigate further the other Diskspd options. But before we do that we have to build a dictionary of what is measured with IOMETER and see the corrisponding terms used by DISKSPD.
BINDING IOMETER RESULTS TO DISKSPD RESULTS

If I look in the Diskspd help, and I try to reproduce the variables of IOmeter, I can build the following table of matches:

  • IOMETER Transfer request size = DISKSPD -b parameter, described as ‘Size of the IO in KB
  • IOMETER Percent Read/Write Distribution = DISKSPD –w, described as ‘Percentage of writes
  • IOMETER Percent Random/Sequential Distribution = DISKSPD –r, which forces Random operations
  • IOMETER # of Outstanding I/Os = DISKSPD –o, described as ‘Outstanding IOs or queue depth (per thread)
At this moment we have no idea of what kind of workload we have to generate to get meaningful results that can help me assess storage performance, and Jose Barreto himself states that we have to experiment with the –t and the –o parameter until we find the combination that gives the best results.

Now guess which tool I am going to use to automate this task in the next post of this series: PowerShell! Stay tuned!

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...