|
Linux 2.6 and Hyper-Threading - MySQL continued and Java 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.
|