Performance during Multi-Threaded Reading/Writing

With this pattern we will explore the controller’s ability to perform multi-threaded sequential reading and writing by emulating several applications demanding large files all at the same time. IOMeter’s test agent (called Worker) that emulates an application sequentially reads/writes 64KB blocks of data starting from a certain sector. By increasing the number of requests coming from one Worker (from 1 to 8 stepping 1) we examine the ability of the drive or controller to reorder the requests (to glue several requests to sequentially located data together into one request). By increasing the number of the Workers we put a heavier load on the disk subsystem – like in the real environment when several applications are competing to access the drives. Each Worker works with its own data (i.e. the data addresses requested by the Workers are different).

The diagram below shows the speed of the arrays at a load of 1 request as the most probable in real environment. The RAID0 arrays are all marked with the same color, the RAID5 arrays with another, and the mirroring arrays with a third color. The order of the arrays in the diagram corresponds to their order in the legend: the higher the bar, the more disks there are in the array.

The read speed does not clearly depend on the number of drives with RAID0 or RAID5 at the 1-request load. The single drive proved to be faster than the RAID1, while the RAID10 had the highest speed. Considering that the RAID0 didn’t do any better, neither controller nor the drives perform anticipatory reading.

When there are two threads to be processed simultaneously, the RAID1 is on top (it’s the ideal case for it because each disk gives out its own data). The other arrays have become slower, although the speed/number-of-disks correction with RAID0 and RAID5 has become apparent. Of course, when there are two threads, the heads of the hard drives have to constantly move between the two operational zones, so the array can’t have the same speed as at linear reading.

The hard disk drives we use in our tests are server-optimized, i.e. have a very small access time. That’s why you shouldn’t expect anticipatory reading from them. But it is not quite clear why the controller doesn’t do it when we had selected Adaptive Read Ahead in the settings. Where’s the adaptability of the algorithm?

When there are even more threads, the speeds of the RAID0 and RAID5 grow up, while the mirroring arrays slow down.