Multithreaded Read & Write Patterns
The multithreaded tests simulate a situation when there are one to four clients accessing the disk subsystem all at the same time – the clients’ address zones do not overlap. The number of simultaneous requests from each of them varies from 1 to 8, but 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 disk subsystem’s performance doesn’t depend much on the number of applications. You can also click the following links for the full results:
When it comes to multithreaded reading from flash-memory drives, you cannot expect exciting results because with such storage devices, there is no difference what address to read data from – all disk addresses are virtually equivalent. You can only expect unusual results from some poorly designed controller. Anyway, it is only the SSD from Intel that can handle a second data thread without a significant performance hit. The other SSDs slow down considerably. Funnily, the JMicron-based outsiders lose less speed – only about 10% as compared to the other drives’ performance hit of 30% or something. It looks like the block-based access together with a multi-channel controller produces an effect at multithreaded reading, and that effect is not positive.
When there are four data threads to be processed, the Indilinx-based SSDs wake up and accelerate. That’s nice on their part, yet we don’t think this can save the day for those drives. No user will deliberately run four disk access threads just because the drive prefers it that way.
The multithreaded writing is not so interesting. The SSDs all slow down somewhat when there are more data threads than one to write. The only exception is the SSD from Intel which does not slow down and takes second place when processing multiple write threads. The SLC-memory drives are surprisingly slow here. SLC memory is supposed to be fast at writing, but we don’t see that in practical applications.