Performance in Intel IOMeter DataBase Pattern

As usual we will start with the results obtained during mixed requests processing. In this pattern we will check how well the controller can handle read and write requests for 8KB data blocks with random address. By changing the read-to-write requests ratio we will be able to see how efficient the controller driver is for sorting requests out.

The table with the overall performance results comes first:

Now take a look at the graphs showing the dependence of the data transfer rates on the relative density of writes. Each graph corresponds to a different requests queue depth: 1, 16 and 256 requests:

Under the linear workload in RandomRead mode all arrays perform similarly. As the share of write requests increases, the HDDs can perform lazy writing more efficiently so the overall array performance improves. The maximum results for all RAID arrays are obtained in RandomWrite mode as we have expected.

The RAID 1 mirror array graph is almost the same as the single HDD graph with small share of writes. As the number of writes grows up RAID 1 array slows down and falls behind the single HDD. The second mirrored array, RAID 10, is slower than 2-HDD RAID 0 array in all modes.

As the workload grows higher, the arrays performance starts depending more on the array type and the number of hard disk drives it is built of, independent of the number of reads and writes among the processed requests.

Note that all mirrored arrays are faster than RAID 0 arrays of the same number of hard disk drives in RandomRead mode, but slower in RandomWrite mode.

The controller can manipulate the read requests and process them on the most ready/convenient/well-rested hard disk drive, so that to achieve the highest performance and efficiency. However, when it comes to writing, the situation is just the opposite. To ensure that the data is identical on both hard drives of the mirrored pair should receive positive write confirmation from each of the drives, which causes additional delays (ideally, it would also have to perform control reading, though).

As the queue depth increases to 256 requests, the situation doesn’t really get any different. The only exception is the workmodes with dominating number of read requests, where the performance grows up significantly due to TCQ technology.