SQL Stress Tool Benchmark

Our first benchmark was custom-written in .NET, using ADO.NET to connect to the database. The AnandTech Forums database, which is over 14GB in size at the time of the benchmark, was used as the source database. We'll dub this benchmark tool "SQL Stress Tool" for the purposes of discussing what it does. We have done some updates to the tool since we first used it; it now supports Oracle, and MySQL. We also adjusted the test time for this test and future tests to 20 minutes. The reason for this was to ensure that we used as much memory as possible for future planned 64 bit tests.


Click to enlarge.

SQL Stress allows us to specify the following: an XML based workload file for the test, how long the test should run, and how many threads it should use in which to load the database. The XML workload file contains queries that we want executed against the database, and some random ID generator queries that populate a memory resident array with ID's to be used in conjunction with our workload queries. The purpose of using random ID's is to keep the test as real-world as possible by selecting random data. This test should give us a lot of room for growth, as the workload can be whatever we want in future tests.

Example workload:


    Select1
    select count(iuserid) as usercount from ftdb_forumusers where iforumid = 1


    Select2
    select count(u.iuserid) as currusercount from ftdb_users u,ftdb_forumusers fu where fu.iforumid = 1 and u.iuserid = fu.iuserid and dtlastvisiteddate > '[q]qGetLastVisitDate[/q]'

Example Random ID Generator:


    qGetLastVisitDate
    select dtlastvisiteddate,newid() as ldate from ftdb_users where dtlastvisiteddate is not null order by ldate


The workload used for the test was based on every day use of the Forums, which are running FuseTalk. We took the most popular queries and put them in the workload. Functions, such as reading threads and messages, getting user information, inserting threads and messages, and reading private messages, were in the spotlight. Each reiteration of the test was run for 20 minutes, with the first being from a cold boot. SQL was restarted in-between each test that was run consecutively.

The importance of this test is that it is as real world as you can get; for us, the performance in this test directly influences what upgrade decisions we make for our own IT infrastructure.


Test hardware configuration SQL Stress Results
Comments Locked

97 Comments

View All Comments

  • semo - Tuesday, February 15, 2005 - link

    is it possible to have a dual proc setup without using registered memory?
  • Proton - Tuesday, February 15, 2005 - link

    "We did a revamp of the tool itself, which is more performant on high volume queries."

    Performant?
    Please read this article...
    http://msdn.microsoft.com/msdnmag/issues/05/03/Edi...

    "More recently, we've seen the word "performant" start its crawl into the everyday vocabulary of devspace. It is used to mean "highly performing." It's also not a word. When something provides information, it's informative. It's not "informant." The word "performant," if it existed, would be a noun—not an adjective. But it doesn't exist, so if you do see it in print, remember that it's not really there.'
  • ceefka - Tuesday, February 15, 2005 - link

    #15 Jason, let me rephrase that#10: "However compact"... That would do it more justice ;-)

    I didn't thank you for the effort you and Ross put into this, did I? Your article came out together with the announcements of AMD. Hot stuff! How much time/sleep did you really have?
  • Viditor - Tuesday, February 15, 2005 - link

    "What memory timings?"

    Good question...

    "is it dual vs Dual or single vs single"

    single vs single, 32bit
  • prd00 - Tuesday, February 15, 2005 - link

    Wait... I think I miss something here.. is it dual vs Dual or single vs single?
  • Zebo - Tuesday, February 15, 2005 - link

    What memory timings?
  • Viditor - Tuesday, February 15, 2005 - link

    "I don't know if it fixes the IOMMU issue or not"

    As far as we know, it doesn't. The Smithfield is a desktop part, so that is to be expected...large quantities of memory aren't yet necessary for the desktop.

    "Now this is interesting. Somewhere were Intel comes out on top by a big margin"

    (grin) Only the most diehard AMD fan would deny Xeon's capabilities...
    For a 1 or 2 CPU server that is used for low-end database serving or webserving, the new Xeon is excellent in 32bit (the CPU of choice)!
    As the next few months grind ahead, we will see quite a few scenarios on review sites. My own suppositions are that

    1. In a 1 or 2 single core Opteron system there is almost no bandwidth constraint. This is evidenced by the lack of change with the 25% HT increase to 1GHz. That said, we might see significant changes in 4 and 8 way systems, especially as dual cores come on-line.
    2. We still have no reviews of these two platforms in 64bit using >4GB of ram. I suspect that Opteron will be much more effective there...
    3. When Intel releases their mp Xeon Nocona, I suspect that 4 and 8 way Opteron systems will blow their doors off...my rationale is that the 1GHz HT links and AMD's MOESI cache protocol gives them a huge advantage in scaling processors.
  • Staples - Tuesday, February 15, 2005 - link

    Now this is interesting. Somewhere were Intel comes out on top by a big margin.
  • fitten - Monday, February 14, 2005 - link

    BTW... there is a new chipset (or some new chipsets) being released soon along with the Smithdale CPU. I don't know if it fixes the IOMMU issue or not, but it might be worth a look...
  • Viditor - Monday, February 14, 2005 - link

    "no mention in any of the access scenarios is described as 32bit..."

    Oops...yes it does.

    "Some devices, such as a large majority of PCI cards cannot directly access memory above the 4GB point"

Log in

Don't have an account? Sign up now