The data you most likely want to get from the above output include the throughput metrics and the latency metrics (highlighted in boldface). Now, getting the throughput and latency metrics from the above single output is easy. But very rarely you'd just run sqlio.exe once to get a single data point, which in itself would not be very useful.

Often, you'd run sqlio.exe in a series with a range of parameter values such as different outstanding I/Os so that you can profile an I/O path. You can write a script to drive sqlio.exe with different parameters. Or, you can accomplish the I/O profiling with a simple batch file such as the following with the outstanding I/Os ranging from 1 through 128:

In practice, your batch file may be much longer than this when you want to test, for instance, different I/O paths and different block sizes. In any event, you'll end up with lengthy output and/or have to deal with the output of a batch file multiple times or even many times when you repeat your test to check for data consistency.

Manually extracting throughput metrics and latency metrics is simply out of the question.

Fortunately, parsing the sqlio.exe output to extract the metrics data is rather simple with any language that supports regular expressions and facilitates text manipulation. Below is a Perl script I use to parse the sqlio.exe output and dump the metrics data and the sqlio.exe command-line parameter values into a csv formatted text file for import into Excel.

This is really just a throw-away script. If you need to arrange the columns or the rows differently, you should modify the script to suit your own need. Or if you run sqlio.exe with the parameters in different order, you'll have to change the regular expression that parses the sqlio.exe command line. I can't predict your requirements (heck, I can't even forecast my own requirements) to put the script in a canned program. But I have no reason at all to worry about the constantly changing requirements or the circumstances I have not programmed the script to handle, because all I have to do is to change the script as I see the need. No heavy initial investment at all! That's the beauty of using a simple throw-away script like this with the source code in plain view.

The script has saved me a lot of time working with sqlio.exe. Hopefully, you'll find it useful as well if you happen to use sqlio.exe.

You probably had to mention about sqlio test that the numbers it provides can be used ONLY for comparison purposes between different drives or configurations. Numbers by itself make no sence most of the time.

For instance, when i run sequential read on my local drive, i get 4037 IOPS and write sequential: 8258 IOPS.

No drive in a world (at least to my knowledge) provides even 1/10 of that throughput. we probably have clues how to explain it. But fact is the fact about it.

Now, some 'smart' manufacturers of SAN devices, like Equalogic,Inc use these numbers to over report their devices performance. They use absolute numbers reported for their devices:

This is pure missleading. Again, what is important to understand is the limitations of this utility. by the way, Equalogic does not use sqlio test which would report 10 - 20 times smaller numbers. And I beleive on purpose.