Linux 2.6 and Hyper-Threading - MySQL continued and Java
Published on 2004-02-23 12:10:07 By: Jim_

The second "smack" that we ended up running on all of our test systems performs one SELECT and one UPDATE. This should give us a sense of how well our test systems will write data to the database. If you'd like to take a look at the UPDATE test file, here it is. Let's look at the graph and we'll discuss it.

Once again, all tests were run five times and the results averaged.

Here we see a role reversal from the last round of testing. Prescott actually pulls ahead of Northwood in this test, and I have a feeling that this time we're seeing the benefit of the additional cache. We're also starting to see some truth to Intel's claim of improved hyper-threading on Prescott. Here we see a ~22.3% increase in performance on the Prescott with HT enabled while Northwood only sees a negligible ~5.6% increase. Go Prescott?

Given the similar scores we see out of the Xeons here, I think we're probably reaching a bottleneck in the system. We might be going as far as our Western Digital 400JB is going to take us. Another thought is that we're being held back by MySQL itself since we're using MyISAM tables and they need to be locked and unlocked when you do an UPDATE. For giggles, I did an 'ALTER TABLE table_name TYPE=Innodb' to convert the table in question over to Innodb as they don't need to lock the tables in this situation. The numbers ended up being very similar, so I ultimately decided that it was in fact the disk that was holding the dual Xeon box back.

Fiddling around with DOTS got my Java juices flowing and when that project fell through for me, I decided to dig around for another Java server benchmark. Only one popular benchmark seemed to present itself and that was VolanoMark. It simulates a Java-based IRC server fielding client connections. It's supposed to stress the scheduler and SMP scalability. I bolded the last part because initially I thought this was going to be a fantastic indicator of HT/SMP performance. Unfortunately, once you see the results I ended up with, you'll probably end up as disappointed as I was.

Confused? I certainly was. We have a lot to go over after glancing at these results. First, why on earth do the Xeons perform so badly in this benchmark? The only real explanation is that VolanoMark (Java) really loves bandwidth and it was just licking up the 800MHz FSB on the two Pentium 4 processors. That's really the only way I can explain those results.

Notice that the Xeons were the only processors that actually gained from having HT enabled? Both of our uniprocessor test systems suffered miserably when HT was enabled.

Here's something else to try and wrap your head around; these numbers are another indication of the improved HT performance on the Prescott. Yes, its results were better with HT disabled but when enabling HT we only saw a decrease in performance in the neighborhood of 12%. The Northwood-based processor suffered a 35% decrease in performance. Morbid, but true.

[ Back to Page 4 ]
 
[ Next to Page 6 ]