Intel Xeon 3.6 (Nocona) vs. AMD Opteron 250 - Database Test
by Jason Clark & Ross Whitehead on September 13, 2004 12:05 AM EST- Posted in
- IT Computing
"Order Entry" Stress Test: Measuring Enterprise Class Performance
One complaint we've historically received about 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 OrderThe above is only intended as an overview of the stored procedure functionality; obviously, the stored procedures perform other validation, and audit operations.
sp_AddLineItem - inserts a Line Item for an Order
sp_UpdateOrderShippingStatus - updates an 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
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 that 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 autogrow 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 was 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.
Facebook
Twitter
RSS
44 Comments
View All Comments
appu - Monday, September 13, 2004 - link
#10, I agree with you. I think before doing an AMD vs. Intel shootout a Prestonia vs. Nocona was more in order.Marlin1975 - Monday, September 13, 2004 - link
Another thing I did not see, maybe missed it?, was the 3.6Ghz P4/Xeon is MORE a paper launch then anything as I can't seem to find it anywhere. The higgest Xeon I see in real quanity is the 3.4Ghz.So is it fair to compare a almost impossiable and even higher priced CPU to one that is easy to find and cheaper?
vmajor - Monday, September 13, 2004 - link
Ah, so AMD farted out the specs?"When AMD first broke wind with the K8 announcement.."
That's one way to grab attention...
Victor
Jalf - Monday, September 13, 2004 - link
#8: Well, why should they? It looks like even Intel are starting to realize that performance doesn't equal MHz. They have much easier and more effective ways to improve their performance than to strive for 4GHzgherald - Monday, September 13, 2004 - link
Well well well... a couple of inconclusive 32bit benchmarks.What this article shows that we didn't already know or didn't expect:
- Nothing.
What this article shows that we already knew:
- The Xeon shared FSB is a significant limiting factor.
What this article shows that we did expect:
- The Nocona performs similarly to the Opteron 250 in 32bits.
What this article did not cover:
- 64BIT BENCHMARKS !
- 64BIT vs. 32BIT !
- How do 2xNocona and 2xPrestonia compare at EQUAL clockspeeds? (i.e. exactly how does the decreased cache and longer pipeline affect numbers)
- How does a 1xNocona compare to an equally clocked Prescott and Northwood? (i.e is it just about equal to the Prescott, as one might expect?)
What this article neglected to mention:
- How did the Nocona's use of DDR2 affect the benchmarks, if at all?
- More importantly, how does it affect price vs. performance ? DDR2 is still twice as expensive and offers virtually no performance improvement, right? So assuming the 3.6 Nocona sells at a similar price to the Opteron 250, you still have to factor in the increased memory costs and when packing in 4GB, as with these test systems, it is no mean consideration!
To #9: AMD is in no hurry to do this, what with DDR2 costing twice as much and offering no tangible benefits as of yet.
fergiboy - Monday, September 13, 2004 - link
It is interesting to note that the Intel platform runs on DDR2. AMD is going to have to tweak its processor to release DDR2 support due to the on die memory controller.sprockkets - Monday, September 13, 2004 - link
There will be versions of Prescott that will have more cache. The question is, will it ever reach 4.0ghz without melt down hahaha.hirschma - Monday, September 13, 2004 - link
I'm not sure how cache effects database performance - I'd guess not very much, but I honestly don't know. If my guess is right, AMD is on track to scale right by Intel very shortly.Denial - Monday, September 13, 2004 - link
Nice article Jason, and please keep the server based benchmarks coming. It's refreshing to see numbers from a reputable source, and though the actual results here may not influence many purchases, it at least gets the "Opteron is a viable option" point across.The slight difference between the top of the line Opteron and Xeon is so slim that the choice of a platform would obviously come down to other more relevant factors. The scores are also so close that it if another application were used the Xeon could come out ahead.
The only real way to know if there is any meaningful performance difference between Xeon and Opteron systems would be to benchmark the application you will be using on systems from your vendors of choice. If the difference is less than 10%, more than likely the TCO, support, organizational standards, and more often than not a good sales team will drive the choice of which systems will be purchased. Unfortunately for AnandTech, they'd have to test the systems as they come from the manufacturers, storage and all, for the benchmarks to be useful to a large organization. There can be a very noticeable difference in performance from an HP, IBM and SUN server all using the same processor.
The interesting data will come when we have 64 bit benchmarks using these CPU's. Win64 with 8-32GB of RAM and 64 bit versions of MS SQL, DB2, Oracle, etc., will be much more informative and useful.
DrMrLordX - Monday, September 13, 2004 - link
Might be nice, knightcrow. I haven't seen those used in many(if any) hardware benchmark reviews, though. At least they made mention of the 2% deviation they got with benchmark results.I don't think anybody's really surprised here. I would, however, like to hear from AMDjihad. He's ever-so-insightful.