"Order Entry" Stress Test: Measuring Enterprise Class Performance

One complaint that we've historically received regarding our Forums database test was that it isn't strenuous enough for some of the Enterprise customers to make a good decision based on the results.

In our infinite desire to please everyone, we worked very closely with a company that could provide us with a truly Enterprise Class SQL stress application. We cannot reveal the identity of the Corporation that provided us with the application because of non-disclosure agreements in place. As a result, we will not go into specifics of the application, but rather provide an overview of its database interaction so that you can grasp the profile of this application, and understand the results of the tests better (and how they relate to your database environment).

We will use an Order Entry system as an analogy for how this test interacts with the database. All interaction with the database is via stored procedures. The main stored procedures used during the test are:

sp_AddOrder - inserts an Order
sp_AddLineItem - inserts a Line Item for an Order
sp_UpdateOrderShippingStatus - updates a status to "Shipped"
sp_AssignOrderToLoadingDock - inserts a record to indicate from which Loading Dock the Order should be shipped
sp_AddLoadingDock - inserts a new record to define an available Loading Dock
sp_GetOrderAndLineItems - selects all information related to an Order and its Line Items

The above is only intended as an overview of the stored procedure functionality; obviously, the stored procedures perform other validation, and audit operations.

Each Order had a random number of Line Items, ranging from one to three. Also randomized was the Line Items chosen for an order, from a pool of approximately 1500 line items.

Each test was run for 10 minutes and was repeated three times. The average between the three tests was used. The number of Reads to Writes was maintained at 10 reads for every write. We debated for a long while about which ratio of reads to writes would best serve the benchmark, and we decided that there was no correct answer. So, we went with 10.

The application was developed using C#, and all database connectivity was accomplished using ADO.NET and 20 threads - 10 for reading and 10 for inserting.

So, to ensure that IO was not the bottleneck, each test was started with an empty database and expanded to ensure that auto-grow activity did not occur during the test. Additionally, a gigabit switch was used between the client and the server. During the execution of the tests, there were no applications running on the server or monitoring software. Task Manager, Profiler, and Performance Monitor were used when establishing the baseline for the test, but never during execution of the tests.

At the beginning of each platform, both the server and client workstation were rebooted to ensure a clean and consistent environment. The database was always copied to the 8-disk RAID 0 array with no other files present to ensure that file placement and fragmentation was consistent between runs. In between each of the three tests, the database was deleted, and the empty one was copied again to the clean array. SQL Server was not restarted.

SQL Stress Results Order Entry Results
Comments Locked

144 Comments

View All Comments

  • Zebo - Friday, April 22, 2005 - link

    It's all good Jep. I was mainly hoping you'd link me to a real live X2 over at xtreme which is why I persisted;)
  • Minotar - Friday, April 22, 2005 - link

    All I can say is WOW!!! AMD keeps kicking more and more ass!!!!!!
  • Jep4444 - Friday, April 22, 2005 - link

    why would i make this up? im just saying what i was told, for all i know that person made it up

    PS if anyone tries to comment and i dont respond within the next 3 days, its cause i wont be on, not cause im backing out of what i said
  • Zebo - Friday, April 22, 2005 - link

    Frankey Jep I'm not buying it. It would cost AMD signifigantly more to make these dual 1MB L2 cores different at the core level. 8XX, 2XX, 1XX, and X2 are identical except for tracing in the pakageing and pins to make them function differently. Check out Tomshardware's recent CPU article about AMD manufacturing and you'll see what I'm talking.
  • Jep4444 - Friday, April 22, 2005 - link

    im not trying to start a rumour, im very much pro AMD(and if you knew me, i generally dislike attention)

    all im saying is dont decided it'll be so fast until we see the real thing
  • Son of a N00b - Friday, April 22, 2005 - link

    #107......rumor.....looking for attentin....engineering sample...of course rushed....BIOS........shhhh jep...........period

    :-P
  • Filibuster - Friday, April 22, 2005 - link

    If you've actually read through this entire thing, congratulations!
  • Jep4444 - Friday, April 22, 2005 - link

    #98 what i heard is from word of mouth, not from the site itself

    while it is true they don't OC very well, apparently the Athlon X2 was rushed and so its functionality wasn't as good as the Opteron 875

    from what i hear they don't multi-task nearly aswell as the Opteron does but single threaded performance should still be up to par

    the Athlon 64 has had changes made to the ALU amongst other places which would differentiate it from the Opteron aswell

    keep in mind i have no actual proof of this and i would love to be wrong but the guys at XS generally know what they're talking about
  • UzairH - Friday, April 22, 2005 - link

    AT should run the doom 3 tests again, this time not using the timedemo but actual gameplay run-throughs. If Doom3 uses a seperate thread for physics then dual-core should definitely benefit.
  • fitten - Friday, April 22, 2005 - link

    #102 ++

Log in

Don't have an account? Sign up now