To give you an idea of the scale of this benchmark we have graphs of stored procedures calls per second. We decided to focus on Stored Procedures / Second rather than Transactions / Second as the definition of a Transaction can have a business context or a technical context.



An interesting preview of the results to come: in 2-way configurations the Xeon is actually able to slightly outperform the Opteron. The added cache and 3.0GHz+ clock speed does seem to help the Xeon tremendously.



The Opteron goes from lagging slightly behind the Xeon to offering a 8.5% performance advantage in a 4-way configuration. The Xeon's shared FSB severely clips its wings when moving to a 4-way setup.

If you're familiar with these sort of database applications, the above graphs will give you a good idea of what sort of stress we're putting on these systems; we are pushing enterprise class performance limits. Now onto the results:

“Order Entry” Stress Test: Measuring Enterprise Class Performance Order Entry Stress Test Results
Comments Locked

58 Comments

View All Comments

  • Rand - Friday, May 20, 2005 - link

  • perlgreen - Tuesday, June 1, 2004 - link

    Is there any chance that you guys could do more tests and benchmarking on Linux for IT Computing/Servers? I really like your site, but it'd be really nice if there would be more stuff for fans of the Penguin!

    cheers,

    Campbell
  • ragusauce - Friday, March 5, 2004 - link

    #54
    We have been building from source and trying different options / debug versions...
  • DBBoy - Friday, March 5, 2004 - link

    #47 - In OLAP, or poorly indexed environments where the amount of data exceeds the 4 MB L3 cache of the Xeons the Opteron is going to shine even more with it's increased memory bandwidth.

    Assuming you do not bottleneck on the disk IO the SQL cache/RAM will be utilised much more thus putting more of a burden on the FSB of the Xeons in addition to allowing the Opteron's memory bandwidth to display it's abilities.
  • Jason Clark - Friday, March 5, 2004 - link

    ragusauce, using binaries or building from source?

    Cheers
  • ragusauce - Friday, March 5, 2004 - link

    We have been doing extensive testing of MySQL64 on Opteron and have had problems with seg faults as well.
  • zarjad - Thursday, March 4, 2004 - link

    Great, thanks.
    My thoughts:
    In this type of application you are likely to use more than 4GB memory.
    Memory bandwidth should matter because you will be doing a lot of full table scans (as opposed to using indexes).
  • Jason Clark - Thursday, March 4, 2004 - link

    zarjad, I'll get back to you on that question I have some thoughts and amd discussing them with one of the guys that worked with us on the tests (Ross).
  • zarjad - Thursday, March 4, 2004 - link

    Jason, any comments on #47?
  • Jason Clark - Wednesday, March 3, 2004 - link

    The os used was windows 2003 enterprise which does indeed support NUMA. So NUMA was enabled.. this was covered in an earlier response.

Log in

Don't have an account? Sign up now