Web-server – Web- and DB-Server: High clock rate and less cores vs. less clock rate and many cores

email-servermulti-coreopteronweb-serverxeon

I am currently looking into setting up a new infrastructure for a hosting project of mine. Basically it will be managed hosting with a strong focus on Django-based apps. All will be Linux-based of course with PostgreSQL as DB and either nginx or Apache as web server along with GUnicorn etc.

Now I am scouting the market for server systems to rent and it is tough to get things that fit the budget and all criteria. So I would like to ask for advice on the following.

All the good offers I could find either use single high end XEON E3-12xx (Quads @ >= 3.2Ghz) or many core Opterons (either 6000 or older with 8 cores or more @ 2.00 – 2.40 GHz). From an I/O POV, both usually have HW-RAID10 with battery, enough RAM to satisfy my needs (24-32 GiB ECC-RAM) and a 1 Gbit/s uplink. A single offer I found is also rather nice but is based on two E5620 XEONs which are rather dated imho and that system is offered at the same price as the others.

Now I am torn. The XEONs do outperform the Opterons hands down in every synthetic benchmark I have seen – emphasis on synthetic. But it is my strong believe that many cores do offer great benefit when it comes to a server's work where a lot more is to do in parallel (e.g. also less expensive context switching). But with a difference in 1 Ghz or more per core, I am no longer so sure because in my case, I am comparing different micro-architectures (XEON vs. Opteron) and different generations as well.

So I'd like to ask the community: More cores at a lower rate or less cores at a higher rate for an app-centric web server that also has to handle the DB load?

The mail system is another story. Ideally I would like to have mail, db and web on three different servers. But that's not in the budget right now. So depending on what system I get for the web server, it is possible that the mail system could end up on that system as well… which would be sub-optimal, I know. I am worried here how much all the small writes from the mail system would effect the DB and Web performance. With 32 GiB of RAM for example, the DB will fit completely in RAM for the very near future until the service has grown considerably (if ever).

One possible (more or less optimal) scenario: Web and DB on an 8 core Opteron 62xx @ 2 Ghz box (everything else as above) and the mail system on a smaller E3-1230 for example. But I am again very worried by the Opteron's performance. 🙁

Tough decision. Again, I'd appreciate any advice/help I could get.

Thanks a lot in advance…

UPDATE(11/08/11 @ 1518 GMT): Basically I am comparing Sandy Bridge E3-12×0 XEONs with Magny-Cours/Zurich/Interlagos Opterons. Unfortunately I cannot get my hands on an Ivy Bridge based dedicated server. Based on the apache benchmarks and cpubenchmark.net results, the E3-1270v1 seems like a true workhorse which will outperform even a dual E5620 and most Opterons thrown at it which is kind of unbelievable. Naturally most of those tests are still synthetic and there are other bottlenecks to consider. But at this stage I want to lay a solid foundation for the future, so I won't be CPU bound too easily.

My intuition has always been more cores and/or processors for a web/db server instead of a higher clock rate at the expense of the amount of cores/processors. So looking at a 4C setup with the E3-1270 for example, feels like the wrong thing to do.

By the way, the hosting will be a product I am offering my clients, so it is not a single product I can benchmark. Basically it will be almost always Django-based apps, mostly CMS systems with custom functionality or custom projects.

Right now I am really considering a nice E3-1270 system as the combined Web- and DB-Server and a E3-1220 as the mail system. Both with fast RAIDs and plenty of RAM naturally. I am still rather worried though that the real 4C will pose a problem in the production environment soonish. 🙁 But if I get a Opteron 6274 based system, I will have to run the mail system on that system as well, which is not very ideal. And besides, according to cpubenchmark.net it is not too much faster… but again: synthetic benchmark. 🙁

Basically what I am asking myself: Will a e.g. Opteron 6274 or 2x 6128 outperform a E3-1270 in a real world scenario or will the E3-1270 still win? Is it the right decision for a solid foundation?

Again, if anyone has any good suggestions and/or advice for me, it is very much appreciated because I am stuck in a feedback loop in my brain right now. 🙂

UPDATE(12/08/11 @ 1835 GMT) Thanks to everyone for their help. Right now I am investigating a totally different approach: Hosting my client's projects and such over at Heroku or Google AppEngine and thus avoiding most of this trouble in advance. 😉 For the mail system, a E3-12×0 will totally suffice, so I would save myself all the headache with a combined web/app/db server which would not be very scalable in the end after all. I'll have to do some further investigating if this would be possible without any major limitations… but I am hopeful. 🙂

Best Answer

There is a lot more to your question than just cores and performance.

  • How many concurrent users does your server need to support?
  • Are you with one server and no redundancy? What is the acceptable downtime for your application?
  • Have you done any benchmark of your development machine for this application to somewhat extrapolate performance?

You may be too worried if you do not expect too much traffic. If you want to put all your apps on a single server, you risk complete outage if hardware has issues. See if you can go for 2x lower machines and distribute the load. For performance, you can dedicate cores to PostgreSQL process using taskset so DB performance is manageable.

If you manage your disks well, then you may get better performance as well. For example, set 2 disks in RAID 1 for pg_xlog.

The long answer is, benchmark your application, and consider redundancy if you cannot afford downtime. Also, compare costs with cloud solutions which will help if your application can scale.

Related Topic