AMD Opteron 248 vs. Intel Xeon 2.8: 2-way Web Servers go Head to Head
by Anand Lal Shimpi & Jason Clark on December 17, 2003 9:15 AM EST- Posted in
- IT Computing
The launch of the Athlon MP was a bittersweet victory for AMD just under two years ago. AMD was able to deliver performance that was significantly faster than Intel’s brand new Xeon, but despite performance leadership, the CPU never really took off.
AMD had limited success in the server market with the Athlon MP, with most of their sales going to HPC customers for large clusters, but very few sales in the web and database server arenas. With no Tier 1 OEMs supporting the platform, most of the larger IT firms wouldn’t touch the Athlon MP with a 10-foot pole, so Intel enjoyed uninterrupted dominance in the web/database server markets.
By the end of the Athlon MP’s life, Intel’s performance had improved significantly to the point where AMD no longer held a performance advantage (although their usual low cost was a factor), further reducing any reason to pursue Athlon MP based servers.
The launch of the Opteron processor gave AMD a much needed breath of new life and energy, especially with the announcement that IBM would be producing servers based on the new Opteron platform. Unfortunately, IBM’s designs are, once again, targeted at the HPC market and left the web and database servers for Intel and IBM processors to handle.
More recently, Sun announced support for the Opteron in their 2004 product line, but again, it is on the shoulders of the 2nd and 3rd tier manufacturers to provide Opteron solutions for web and database serving applications. But before there can be a demand, there must be some information on the performance of the Opteron in these sorts of applications.
We’ve already seen how the Opteron can perform in most computation-intensive applications as well as workstation applications, but what about as a web server? Or a database server? In our original coverage of AMD’s Opteron, we offered some performance analysis of both web and database server applications with the Opteron, but AMD has made a couple of steps recently to warrant a second look at the performance picture.
First and foremost, the launch of 4-way Opteron platforms has made many of our IT readers (and us included) wonder how a 4-way Opteron would stack up against a 4-way Xeon MP box. With AMD’s more scalable Opteron architecture, any performance advantages a 2-way Opteron had over a 4-way Xeon should, in theory, be greater.
AMD has also recently launched higher clock speed versions of the Opteron at 2.2GHz, equal in speed to the fastest Athlon 64 FX currently available.
But quite possibly one of the biggest reasons for this comparison is that we’ve been looking internally to upgrade our server platforms from the aging Athlon MPs and needed to evaluate the Opteron as a potential upgrade path.
Since we last wrote about our server upgrades at AnandTech, we added a 2-way Xeon DP 2.8GHz server with Hyper-Threading and were pleasantly surprised with the performance offered by the platform. We have also spent a great deal of time looking at 4-way solutions for a potential upgrade to our database servers, also requiring a more in-depth look at the latest in Opteron offerings.
We have more than just this one article to bring to you the full spectrum of Opteron performance; but to kick it all off, we’re going to look at web serving performance in a head-to-head match between the Opteron and Xeon.
We’re not going to rehash any of the Opteron’s architecture in this article, so make sure that you’ve read our Intro to Opteron/K8 Architecture before proceeding.
Facebook
Twitter
RSS
43 Comments
View All Comments
Zuni - Friday, December 19, 2003 - link
"That entirely depends on the application being tested, and the load on the server, and the memory on the server. If you're calling the same 10 files over and over again then they'll likely be cached. If you have a true application where someone hits a page and creates a 600 megabyte recordset"Sure I/O usage would depend on the type of web application being tested. However, most web applications feeding off a database backend would not pull 600 mb recordsets :) Pulling such record sets would be a fairly silly thing to do in most any circumstance. Our test was absolutely not hitting I/O on the webservers, the template cache is more than enough to hold the templates being tested. In fact as I'm writing this I pulled the disk time on one of Anands busiest web servers and its showing less than 1% of disk time :) If an application is well written, and the webserver has a decent amount of memory (most do) then I/O should not be a factor in a run of the mill application such as FuseTalk.
"This smacks of rhetoric. ASP and ASP.NET are also 'very good reference points' as enterprise level application environments. "
Not at all, although I can see how you could draw that conclusion. FuseTalk is currently being ported to .NET, once we have a stable working version or another app we deem worthy of a real world test we’d be glad to run tests on .NET as well. I quite like the platform. This is just the beginning of our server testing and developing real world tests. It takes time, and a lot of it to develop and run theses tests.
Cheers
Zuni - Friday, December 19, 2003 - link
Trog, again RAMDISK was used so that the application server was free to tax the cpus as much as possible instead of waiting for data requests from the database. This has nothing to do with normal or abnormal. We aren’t testing the database here we’re testing the application server, and we wanted no bottlenecks on the backend to cause any skewing on the front end. We don’t have fibre channel backend database hardware just laying around, thus a RAMDISK was used to remove the I/O bottleneck.Again, the database is not in question here or being tested so its irrelevant.
Cheers.
Falco. - Friday, December 19, 2003 - link
" 1) disk subsystem is irrelevant in a web application driven by a database backend. Most any web application server caches the templates in memory so I/O is not a factor. However, each web machine had a 36gb u320 scsi drive. "That entirely depends on the application being tested, and the load on the server, and the memory on the server. If you're calling the same 10 files over and over again then they'll likely be cached. If you have a true application where someone hits a page and creates a 600 megabyte recordset, your disk IO is gonna come in handy right quick. Saying "I/O is not a factor" is misleading.
However, I'm glad they responed the way they did, because if you hvae a testbed that starts to swap or spin out to disk, that doesn't test the CPU as much. I was expecting they'd come back and say they used a test set that was cached compiled templates (which is a good thing). My question was aimed at eliminating it as a possible variable.
" 2) Not sure I understand your friends point really... Of course ColdFusion tests performance, we used FuseTalk as the web application and ColdFusion as the web application server. "
That's not entirely what I meant. Cold Fusion is a middleware layer. It's not a "web server" as per the title of the review (Cold Fusion actually can include its own webserver if you want it to).
I found the title of the review to be somewhat misleading, since it implied they were testing a web server and not an application server.
" ColdFusion in its current version is a J2EE server which allows you to write in the ColdFusion language. After its compiled its the same compiled byte code as any J2EE app. "
Correct; it's an interpreter (CF) running on an interpreted language (Java). It's a good test in that it has multiple subsystems communicating together on top of having to handle actual web serving such as setting up sessions and opening and closing connections.
" We may include .NET in the future, but J2EE is a very good reference point as its a enterprise level application environment. "
This smacks of rhetoric. ASP and ASP.NET are also 'very good reference points' as enterprise level application environments. A whole huge great pile of systems run ASP. It struck me that it would have been worthwhile to round out the review by testing a number of common web application server configurations:
* Pure J2EE
* ColdFusion
* ASP
* ASP.NET
* PHP (although this would not test IIS, as most PHP systems drive it with Apache -- mind you, a test with Apache would be equally interesting)
" Sustained load throughout the test keeping the CPU working in the 80-100% bracket. We measure performance by how long the cpu took to run each code template from start to end. (this was all detailed in the review btw.) "
This part I understood and took for granted. Interestingly if they had sustained 80-100% CPU load, this is an added shine for the AMD parts, because past 70% load on your webserver you should be adding another box or upgrading your CPUs.
TrogdorJW - Thursday, December 18, 2003 - link
Hey Zuni... who are you? Anand? Or "just" an Anandtech employee (or reviewer or whatever)? Anyway, let me clarify:"The entire reason we used a RAMDISK was to ISOLATE the cpu not to hold it back by something else."
Exactly. Ergo, without the RAMDISK holding the database, file I/O can be a much bigger factor than CPU speed. Yes, you can get bigger and faster disk subsystems, but that's not always the way it's done. Anyway, it *sounds* to me like a more "normal" setup on the database side would end up being a major bottleneck on the overall throughput, so that either of these systems is overkill. You need a DB system with a very high I/O rate first, and then looking at these faster CPUs comes second.
On a separate thought, are there going to be some benchmarks *without* using a separate DB server (which used a RAMDISK)? I understand that your site may not run that way, but the vast majority of web servers do, I believe. If you have one server running both the database backend as well as the application services, what do the benchmarks look like? That would be something to look at, surely?
Falco. - Thursday, December 18, 2003 - link
thanks Zuni, i'll let him know and post back any replies he may haveZuni - Thursday, December 18, 2003 - link
Falco,1) disk subsystem is irrelevant in a web application driven by a database backend. Most any web application server caches the templates in memory so I/O is not a factor. However, each web machine had a 36gb u320 scsi drive.
2) Not sure I understand your friends point really... Of course ColdFusion tests performance, we used FuseTalk as the web application and ColdFusion as the web application server. ColdFusion in its current version is a J2EE server which allows you to write in the ColdFusion language. After its compiled its the same compiled byte code as any J2EE app. We may include .NET in the future, but J2EE is a very good reference point as its a enterprise level application environment.
3) Sustained load throughout the test keeping the CPU working in the 80-100% bracket. We measure performance by how long the cpu took to run each code template from start to end. (this was all detailed in the review btw.)
Falco. - Thursday, December 18, 2003 - link
a friend has some questions about this review :Did they get into details about the disk subsystems on each of the web servers? I know they tried to keep the database in ramdisk (even though SQL server will do that anyway if the database is small enough).
What sort of web application were they running? I find it curious they were using a Coldfusion application as well, since that doesn't test web response as much as the cold fusion runtime services; they should have used an ASP or ASP.NET application test, at least as an additional data point.
What did they do to test web response time? Sustained load? stressed load? burst load?
thats what hes asking in a forum i frequent...
Icewind - Thursday, December 18, 2003 - link
Man, how the hell do you learn and keep up with all this server technology, both hardware and software? Im having a hardtime just keeping desktop technology and changes....Zuni - Thursday, December 18, 2003 - link
skiboysteve, because thats what was sent with the systems :) 8GB of it.Zuni - Thursday, December 18, 2003 - link
Visual, the db server didnt need hardly any ram the database was barely 50 MB :) Again the point of the article was to eliminate the db as anything but a boundless data resorce so the web applications servers could process pages as fast as possible, keeping the cpu taxed. This was a 32 bit test, OS etc. We're trying to get ahold of a 64 JVM and we're looking at some UNIX based 64 bit tests for another article.Cheers!