Intel IOMeter: DataBase Pattern

In this pattern we are going to test the controllers’ ability to work with a mixed stream of: read and write requests for 8KB data blocks with random address. By varying the reads-to-writes share in this data stream we can figure out how efficiently the controller driver can sort out different types of requests for more optimal further processing.

Hm.. What a big table. For your convenience I provide the selected results on the diagrams. Have a look:

To tell the truth, it is pretty hard to understand something in this rainbow :) I can only say that Adaptec controller falls quite noticeably behind the competitors when working with a big share of writes. It is remarkable that two controllers based on the same chip showed the best (SiliconImage) and the worst (Adaptec) results under linear workload in this test.

Now let’s increase the queue depth and see if it gives the controllers a chance to stand out somehow.

Well, this seems to have worked: now we can name the three leaders. They are SiliconImage, which proved the best, 3ware, which yields a little bit to the leader in RandomRead and RandomWrite modes, and Adaptec, which performance is very sensitive to the writes share.

As for the diagram with 256 requests queue depth, I decided not to give it here, because it is very hard to read, even harder than the diagram for queue=16.

Instead, I suggest that you take a look at the three tables (click to open), where the best and worst results for all three types of workload are marked in color:

• Database (queue=1): results
• Database (queue=16): results
• Database (queue=256): results

Summing up the performance of our testing participants in DataBase pattern we can single our 3ware and SiliconImage controllers, which managed to defeat all the other competitors.

Now let’s check how successful these controllers will prove in applications emulating the work of the server disk subsystem.