hIOmon DXTI Metric

The hIOmon "DataTransferred/Time Index (DXTI)" is a simple, straightforward metric.  It provides a "high-level" means for relative comparison of I/O operation performance (where basically "higher is better").  That is, the "higher" the Index number, the better the performance – as in more data transferred and/or less required response time (i.e., application wait).

The DXTI metric resembles the "fuel economy" index for an automotive vehicle (i.e., "miles-per-gallon") as an overall measure of "performance efficiency".  It is akin to more miles driven (more data transferred) for fuel used (response time taken to transfer this data), or similarly, same miles (data transferred) but less fuel used (less response time).

The basic concept behind the hIOmon DXTI metric is simple:

Better storage I/O operation performance is fundamentally about transferring (more) data faster

So for a given amount of data, transferring this data more quickly (i.e., in less time).  And similarly, transferring more data within the same amount of time.  More specifically, the relationship is basically between the amount of data transferred and the corresponding amount of time that it took to perform the I/O operations required for the data transfer.

The calculation of the hIOmon DXTI metric is easy and straightforward.  The metric is calculated by simply taking the observed overall total amount of data transferred by the I/O operations (converted to megabytes for scaling), and then dividing this combined total amount by the corresponding combined sum of the observed time durations (i.e., the actual response times) of the I/O operations that were performed to transfer this data.  The resulting value is considered to be an index.

DT = Observed overall total amount of data transferred by the I/O operations (converted to megabytes for scaling)

RT = Corresponding combined sum of the observed time durations (i.e., response times) of the individual I/O operations that were performed to transfer this data

DXTI = DT / RT

It is important to note that the "time" component in this calculation (i.e., the "RT" divisor above) is not the elapsed wall-clock time during which the data was transferred (i.e., the overall time period duration; e.g., a one-minute period during which the corresponding data was transferred).  Nor is it simply/solely the "device busy" time during which the associated device was servicing the corresponding I/O operations.

Rather, the time value is the aggregated sum of the actual response times for the individual I/O operations that performed/requested the data transfers.  Moreover, these individual response times include both the queue time and the service time for the respective I/O operation.

The response time for an individual I/O operation is effectively the amount of time between when the start of the I/O operation was observed by the hIOmon I/O Monitor and when the hIOmon I/O Monitor observed the completion notification for the I/O operation.  From the application/user perspective, the response time is seen as the actual amount of time required to perform the particular data transfer I/O operation request; this time can also be considered as the amount of time waiting for the data transfer I/O operation request to be performed/completed.

The graphic below helps illustrate how the time component used by the DXTI metric is distinct from that used with "overall average MB/s" (a commonly used MB/s metric) and the "device busy" data transfer rate metric.

Imagine a bakery that sells only cookies, which on a given day has sold 900 cookies during the ten hour period when it was open.  Also imagine a storage device that has transferred 900 megabytes of data during a ten second period.

Using "elapsed time" as the time component, the bakery sold cookies at an average rate of 90 cookies an hour.  Similarly, the storage device transferred data at an "overall average" rate of 90 MB/s.  Incidentally, this is the way that many performance benchmarking tools report MB/s within their test results: simply divide the amount of data transferred during the particular test by the elapsed time that it took to run the test.

As one might expect, there were periods during the elaped times when the bakery and storage device were not busy (i.e., no cookies were being sold or data transferred).  Accordingly, another perspective is that of a busy salesperson (i.e., busy selling a customer some cookies) and a busy storage device (i.e., busy processing an I/O operation and performing the respective data transfer).

In the above example, the salesperson was only busy during half of the time that the store was open.   Similarly. the storage device was idle during half of its observation period.  Using "busy" time rather than "elapsed time", the bakery sold cookies at an average rate of 180 cookies an hour (and the storage device transferred data at an average rate of 180 MB/s).

Obviously, stores can have periods of "busy" sales and periods of slow or no sales during store open hours.  Likewise, storage devices can have periods of high activity (e.g., burstiness of I/O operation activity) as well as idle moments if not periods.  So in contrast to elapsed time, the "busy-time" perspective provides a more granular picture of the activity and performance capabilities of the cookies sales and storage device.

An additional perspective is that of the ultimate recipient: the customer buying cookies or the application issuing I/O operations to transfer data with the storage device.

For an individual customer, the time component is the period starting when the customer enters the bakery store and ends when their cookie purchase has completed.  For an individual application I/O operation, the time component is the response time for that I/O operation.  Note that in both cases, the time component includes any waiting for service (i.e., queue time).

For the bakery, the time component for the "Customer Time Index" is the sum of the customers' times.  Note that in this example, this sum is greater than the "salesperson busy time".  This is due to one or more customers having had to wait in line (in queue) while the salesperson served another customer.

For the storage device, the time component for the DXTI is the sum of the all I/O operation response times.  Similar to the bakery example, one or more application I/O operations incurred queue time while waiting for the device to complete processing of other I/O operations.

It is important to note that both the "Customer Time Index" and the DXTI are not rates; they instead reflect an index that has no explicit units (e.g., no named MB, hour, or seconds).

Overall, the hIOmon DXTI metric provides a "high-level" means for relative comparison of I/O performance, where basically "higher is better" (i.e., the higher the Index number, the better the performance).

As previously noted above, this Index metric resembles the "fuel economy" index for an automotive vehicle (i.e., "miles-per-gallon" or "kilometres/litre") as an overall measure of "performance efficiency".  For example, just as more miles traveled for the same amount of fuel is better, transferring more data for the same amount of response time (wait) is better.  Similarly, just as traveling the same distance using less fuel is better, transferring the same amount of data but experiencing less response time (wait) is better.

So essentially a higher relative DXTI metric value indicates better performance efficiency in terms of more data transferred and/or less required response time (wait).

A key consideration to note about the DXTI metric is that it is based upon and directly derived from the two, most-basic factors involved with storage I/O operation performance:

1. The amount of data transferred (DT), and
2. The corresponding amount of time (RT) taken to perform the I/O operations required for the requested data transfer.

The hIOmon DXTI metric is not meant to simply be an overall replacement for the other basic I/O operation performance metrics such as "I/O operations-per-second (IOPS)", "Megabytes-per-second (MB/s)", read/write ratio, random access percentage, etc.

Rather, the DXTI metric provides benefit as an overall indicator of performance efficiency that can be used to help quickly and easily assess, for example, the overall I/O operation performance of a particular device, file, or process/application.  Similarly, the metric can likewise be used to help assess the overall performance of a particular "I/O profile" (e.g., a specific read/write, random/sequential, and data transfer size scenario), including when comparing various devices or other computer system changes.

As previously mentioned, the DXTI metric resembles the automotive "fuel economy" index.  Of course, the "miles-per-gallon (mpg)" value can vary due to a number of factors (such as speed; various traffic, weather, and vehicle conditions; loads/occupants; change in terrain; etc.).  So when, for instance, a low (or less than expected) mpg value is encountered, a deeper analysis might be required that includes the consideration of other metrics (e.g., the average and maximum "miles-per-hour" metrics).

This can similarly be the case when a low or less than expected DXTI metric value is encountered.  Under such circumstances, the investigation of other metrics such as maximum response times, random access percentages, etc. can be warranted.  This is also where the hIOmon "Performance Threshold Range Metrics" can be of great help by enabling you to quickly and easily pinpoint those particular factors that are contributing to the low DXTI metric value.

Bringing Transparency to Disk I/O Performance℠