The scope of this test

Our primary objective for this project is quite extensive, so we have narrowed our scope a little more for this article.

Firstly, we focused on single and dual processing systems.

Secondly, we focused on "read" performance. This means that our benchmarks do not try to write information in the tables, but rather, always fetch and report information from one or more tables.

There are two reasons for this:
  1. We narrow our focus to a certain kind of application based on when write performance plays a minor part compared to read performance.
  2. We want to focus on operation, which involves little harddisk activity, and focus on the platform: the processor(s) and the interaction with the memory.
The benchmarks were inspired by the fact that in many cases, people simply search and browse for information on a website, intranet or another RDBMS application.

So, this article is not about a typical large central database of banks that need to handle a large number of transactions, with frequent writes operations. It is more about a server that needs to handle a lot of ad-hoc queries. AnandTech readers who are searching for a certain article, who like to read the news of the day, or who are checking out the Realtime pricing guide are perfect examples of ad-hoc queries.

Other examples of typical "read heavy" applications are data warehousing applications. The write heavy databases in a company send data to a data warehouse during the night to produce statistical data, which in turn is a read-heavy process.

In these cases, a Systems Administrator or database administrator will try to cache as much information as possible in the fast RAM memory. Database applications and SQL Queries tend to be optimised to be "RAM cache friendly".

Considering that even the best harddisk RAID system accesses information in Milliseconds while RAM memory does the same job in Nanoseconds (Nano is one millionth of Milli), making good use of caching and avoiding storage I/O offers superb performance boosts. As a result, storage I/O limited databases are, in many cases, high end database applications that are run on much more expensive machines than the ones which we are discussing in this article.

Lastly, we test on SUSE SLES 8 (SUSE Enterprise Edition) SP3, Linux kernel 2.4.21. Rest assured that a new report with kernel 2.6 will follow. However, we think that the results might still interest a lot of people as the enterprise market does not upgrade as quickly as desktop users. We found SUSE SLES 8 SP3 Kernel 2.4.21 to be a very stable environment for our database tests.

As a final comment before we move to the benchmarks, I have been working with Anand and his great team for a couple of weeks, and together with your feedback, we will make sure that this project improves over time.

A gigantic market The benchmark
Comments Locked


View All Comments

  • smn198 - Thursday, December 2, 2004 - link

    Would love to see how MS SQL performs in similar tests.
  • mrVW - Thursday, December 2, 2004 - link

    This test seems foolish to me. A 1GB database? All of that fits in ram.

    A database server is all about being the most reliable form of STORAGE, not some worthless repeat queries that you should cache anyway.

    Transactions, logging... I mean how realistic is it to have a 1GB of database on a system with 4GB of RAM and expensive DB2 software.

    A real e-commerce site likeMWave, NewEgg, Crucial could have 20GB per year! Names, addresses, order detail, customer support history, etc.

    Once you get over a certain size, a database is all about disk (putting logging on one disk indepdent of the daata, etc.). The indexes do the main searching work.

    This whole test seems geared to be CPU focused, but only a hardware hacker would apply software in such a crazy way.

  • mrdudesir - Thursday, December 2, 2004 - link

    man i would love to have one of those systems. Great job on the review you guys, its good to know that there are places where you can still get great independent analysis.
  • Zac42 - Thursday, December 2, 2004 - link

    mmmmmmm Quad Opterons......
  • Snoop - Thursday, December 2, 2004 - link

    Great read
  • ksherman - Thursday, December 2, 2004 - link

    is that pic from the 'lab'? (the one on pg 1)

Log in

Don't have an account? Sign up now