Multithreaded Read & Write Patterns
The multithreaded tests simulate a situation when there are one to four clients accessing the virtual disk at the same time, the number of outstanding requests varying from 1 to 8. The clients’ address zones do not overlap. We will discuss diagrams for a request queue of 1 as the most illustrative ones. When the queue is 2 or more requests long, the speed doesn’t depend much on the number of applications.
- IOMeter: Multithreaded Read RAID1+RAID10
- IOMeter: Multithreaded Read RAID5+RAID6
- IOMeter: Multithreaded Write RAID1+RAID10
- IOMeter: Multithreaded Write RAID5+RAID6
When the arrays are reading a single thread, they have predictable standings and deliver high speeds. Of course, you can only see the maximum speeds at a queue depth longer than 1 (like on other controllers we have tested so far in our labs), yet the HighPoint RocketRAID4320 is very good even at the shortest queue.
The addition of a second thread lowers the speed of every array with one exception. Judging by the increased speed of the 4-disk RAID10, this array identifies the two threads and sends each thread to a separate disk of a mirror pair. Unfortunately, the 8-disk RAID10 does not do the same. So, this feature of the controller’s firmware is not stable.
Funnily enough, the RAID10 arrays are both faster with three than with four threads although one might think that it would be easier for them to parallel an even number of threads.
The degraded arrays do not have serious performance hits but are slower than their healthy counterparts.
When the arrays are writing one thread, their standings are logical and predictable and their speeds are high.
When there are two threads to be processed, most of the arrays slow down at the same rate, but there are exceptions: the RAID0 arrays and the ordinary and degraded RAID5 have a smaller performance hit.
There are no changes in the standings when a third and fourth thread is added. The speeds just get lower.