In case of 256 requests queue depth the situation doesn’t look any different from what we observed in WriteThrough mode.
And now let us compare the performance of all RAID arrays with different caching algorithms involved. We will just make one more table, where each cell contains the coefficient obtained as controller performance in WB mode divided by controller performance in WT mode. This way, this coefficient will reflect the efficiency of WB-caching in each particular situation. If the coefficient is smaller than 1 (these results are highlighted in red), it means WB-caching doesn’t make sense here. And if the coefficient is bigger than 1 (these results are given in blue), then WB-caching has a positive effect on the performance in this case.
If you see “1.0”, then WT and WB caching are equally efficient in this mode.
Now I would like to make a few comments about these results. In all arrays driver WB-caching resulted into performance drop in RandomRead mode and performance increase in RandomWrite mode, and slowed down the controller performance in case of 256 requests queue depth.
In case of a single hard disk drive, the WB-caching efficiency increases as the share of write requests grows up, and decreases, as the share of writes drops down. That is why the influence of WB-caching on JBOD performance should be considered from various viewpoints. On the one hand, the performance grows and decreases. On the other hand, the performance drop never gets beyond 3%, while the performance increase sometimes hits 20%.
For all other arrays enabled WB-caching reduces the performance mostly in RandomRead mode when the requests queue depth is 256 requests. The maximum performance drop caused by enabled WB-caching notched 5%, and the maximum performance improvement reached 25%. If you have been checking the table attentively enough, you may have noticed red numbers under linear workload, as well as in case of 64 requests. However, in these cases the performance drops not more than by 2%.
Under linear workload with even share of reads and writes RAID 01 array slows down by about 10%. This mode seems to be the hardest for the driver that is why this spot falls out of the overall picture. It should be a really tough task to make the decision in case of a complex array, especially with even shares of read and write requests.
So, the arrays working with enabled WB-caching in mixed modes with dominating reads always slow down in RandomRead and never slow down in RandomWrite.
As we know from our previous reviews of Promise controllers, enabled WB-caching slows down controller response a little bit during requests processing. The reason of this slow-down is evident for writing operations, because the controller driver spends processor time to think about the most optimal caching strategy (searching through the cached writes trying to find out if there are any requests to be processed together with the newly arriving ones, or arranging the cached requests in the most optimal way for further processing). However, I cannot find a reasonable explanation for the slow-down during reads processing…
Here we see the performance drop in RandomRead mode. As soon as write requests appear in the queue, the performance starts growing up. Moreover, unlike Promise FastTRAK TX4000, the positive effect brought by WB-caching grows smaller as the queue depth increases, i.e. when the controller has something to choose from.
In the general case, when the controller processes writes, WB-caching can be considered highly positive. 256-request queues are a very rare thing in real life that is why enabled WB-caching is very unlikely to harm the system performance. I can think of only one example right now when you’d better not enable the WB-caching: if you have a web-server, which receives almost no write requests at all.