Xeon 2.8GHz DP & 2.0GHz MP - Part I: Taking over the Enterprise

Performance: Answering the Questions

When the Xeon and Athlon MP processors were first released we turned to our own server environment to provide the test tools we need to evaluate the platforms. We recorded a trace of 30 minutes of activity on the AnandTech Forums DB server and then used that as the best way of figuring out the real world performance of these CPUs.

Since we originally ran that test we've added AnandTech Web and Ad DB tests to our suite of database server benchmarks, and we've updated the AnandTech Forums DB test. Our last trace recording of the Forums was when the Forums DB was around 3GB in size, today the database is 10GB large and growing.

When we received the Xeon platfoms for testing we immediately fired up our in house tests and went at it. The first thing we realized was that even our largest, most stressful DB test was not enough to even remotely stress a 4-way Xeon MP server. During our first run of benchmarks we couldn't get the 4-way Xeon MP with Hyper-Threading enabled to ever peak above 20 - 25% CPU utilization; we needed something more stressful than our server environment.

Around the same time that we were working on this article, we were also working on the server setup for AnandTech. Until very recently, we still had two older Pentium III and Pentium III Xeon based database servers running the AnandTech Web DB and the AnandTech Ad DB. Because of their relatively low CPU utilization we were able to consolodate both of those servers into a single modern day server platform, in this case a dual Athlon MP 2200+. While running both DBs on a single server would increase our memory and I/O requirements, it does save on licensing costs and cuts down on rack space as well. To give you an idea of the amount to be saved, a single processor license of SQL Enterprise edition retails for $19,995. The fewer CPUs you have and the fewer systems you have to license, the lower your overall server management costs will be.

This idea of running multiple DBs off of a single box gave us inspiration to try the same with our DB server tests. In essence, instead of having one big database as our testplatform we'd run multiple DBs in order to simulate larger loads. This approach ended up being exactly what we needed as we could finally stress not only the faster 2-way servers, but 4-way servers as well. And at the higher load multiples we were able to simulate tests of databases that weren't 3GB in size, but 24GB in size.