Door Redactie Tweakers

Database test: Intel Xeon 'Clovertown' X5355

14-12-2006 • 15:10

0

Singlepage-opmaak

MySQL 5.0.20a and 5.0.32-bk

The first test case is MySQL 5.0.20a, the same version that we used in all previous reviews. The upscaling step from one to two cores does not reveal anything special. The lower clock speed does make Clovertown a little slower than Woodcrest, the top model, but does not exhibit any unusual behaviour. The step from a single dual-core to a double dual-core also isn’t too remarkable as compared to earlier experiences. When we pit two dual-cores against a single quad, we see that things begin to run somewhat less smoothly. Since only one of the two busses can be used, the available amount of bandwidth has been effectively cut in half. This makes performance go down by about 5% under a heavy load of about 25+ users. The final step to eight cores turns out to be dreadful: MySQL does not understand what is going on any more and the performance diminishes below that of two dual-cores, and finally collapse altogether. On average, the loss in performance is 22% under heavy loads.

Clovertown vs. Woodcrest - MySQL 5.0.20a

This is not the first time we saw MySQL exhibit this sort of behaviour: in the article on the Sun T2000 we reported the same problem. MySQL developers are aware of the problem but when we searched for a solution with Sun at the time, nothing could be done about it yet. For this test, we went out looking for a solution once more, and it turned out that a patch is being readied. It hasn't been officially released, but a MySQL 5.0.32 snapshot from BitKeeper – the system that developers use to manage their source code - allowed us a sneak preview how things stand.

The latest MySQL developments are interesting: it appears as if part of the performance with a low number of cores has been traded for stability when more cores are used. On average, using a single core costs us around 10% of the performance as compared to version 5.0.20a, and with two cores this is down to 4%. At four cores, however, we register a gain of 1% and with eight cores things go 36% better. Also, the peak of 616 requests per second for 5.0.32-bk is clearly better than the 498 that we could squeeze out of 5.0.20a. But still, it turns out that MySQL does not fancy heavy loads too much: after the peak the number of requests per second drops sharply again.

MySQL 5.0.20a vs. 5.0.32-bk