Random Read & Write Patterns
Now we will see the dependence between the controllers’ performance in random read and write modes on the size of the processed data block.
We will discuss the results in two ways. For small-size data chunks we will draw graphs showing the dependence of the amount of operations per second on the data chunk size. For large chunks we will compare performance depending on data-transfer rate in megabytes per second. This approach helps us evaluate the disk subsystem’s performance in two typical scenarios: working with small data chunks is typical for databases. The amount of operations per second is more important than sheer speed then. Working with large data blocks is nearly the same as working with small files, and the traditional measurement of speed in megabytes per second becomes more relevant.
Let’s start with reading.
- IOMeter: Random Read, operations per second
- IOMeter: Random Read, MBps
- IOMeter: Random Write, operations per second
- IOMeter: Random Write, MBps
There are no surprises when the controller is reading small random-address data blocks. The RAID10 is ahead, followed by the single HDD. The others are trailing behind. The results do not depend on the order of tests.
The arrays split up in twos on large data blocks. Reading is stable irrespective of the data chunk size and the previous load. The standings are normal and compatible with what we have seen in the sequential reading test. The RAID0 is ahead, followed by the RAID5. The RAID10 is the worst array here. Its ability to choose a luckier disk in a mirror is an advantage when reading small data blocks, but when the sequential speed becomes the crucial factor (at 2MB blocks), the RAID10 cannot match the other arrays.
It is the amount of available cache memory and the need (or the lack thereof) to calculate checksums that is the decisive factor at writing small data blocks. Take note that the RAID50 is always a little bit faster than the RAID5 as it has to make fewer disk accesses to calculate a checksum. The RAID6 cannot match the RAID50 under this load because the second checksum is quite a burden at random writing.
Interestingly, both test cycles produce almost coinciding results although we are testing writing. You cannot see the difference in the diagrams. Thus, the discrepancy is not due to the controller’s request caching mechanisms.
It is at writing in large data blocks that we can see the huge difference between the two test cycles. This is all quite mysterious. Most of the first-cycle arrays seem to hit against some performance ceiling on large data blocks, even showing some reduction of speed as the data block grows larger. However, the RAID0 did very well in the first cycle but delivered low performance in the second cycle as if finding the same barrier that prevented the other first-cycle arrays from showing their best. This is a very odd behavior, we should say.