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

  • danidentity - Monday, February 14, 2005 - link

    Jason, I hope you're ready for about 5 pages of comments pointing out the flaws in your testing methodology and another 5 pages demanding you re-do all the tests because the Opteron didn't destroy the Xeon.

    Fair warning. ;)
  • Jason Clark - Monday, February 14, 2005 - link

    Tiamat, yep corrected. Thanks
  • Tiamat - Monday, February 14, 2005 - link

    "Dual core Opterons will be socket compatible with existing 950 pin sockets that support 90nm (95W/80A)."

    Correct me if I am incorrect, did you mean 940 pin? If not, I have not seen any 950 pin sockets on the market...
  • Jason Clark - Monday, February 14, 2005 - link

    Aileur, we'll get right on it.
  • Jason Clark - Monday, February 14, 2005 - link

    They are coming soon :) Derek Wilson is going to deliver those.
  • Aileur - Monday, February 14, 2005 - link

    Im afraid youre gonna have to redo this whole article since the opteron doesnt wipe the floor with the xeon, and this is unacceptable.
  • Carfax - Monday, February 14, 2005 - link

    Can you please do some Workstation benchmarks?

    It is rumored that AMD enhanced the SSE2 units aswell as added SSE3 support, and I want to see if it's true.

Log in

Don't have an account? Sign up now