The discussion of Dual vs. Quadcore is as old as the Quadcores itself and the answer is usually "it depends on your scenario". So here the scenario is a Web Server (Windows 2003 (not sure if x32 or x64), 4 GB RAM, IIS, 3.0).

My impression is that the CPU in a Webserver does not need to be THAT fast because requests are usually rather lightweight, so having more (slower) cores should be a better choice as we got many small requests.

But since I do not have much experience with IIS load balancing and since I don't want to spend a lot of money only to find out I've made the wrong choice, can someone who has a bit more experience comment on whether or not More Slower or Fewer Faster cores is better?

+1  A: 

The more the better. As programming languages start to become more complex and abstract, the more processing power that will be required.

Atleat Jeff believes Quadcore is better.

+3  A: 

We use apache on linux, which forks a process to handle requests. We've found that more cores help our throughput, since they reduce the latency of processes waiting to be placed on the run queue. I don't have much experience with IIS, but I imagine the same scenario applies with its thread pool.

Mark Harrison
+12  A: 

For something like a webserver, dividing up the tasks of handling each connection is (relatively) easy. I say it's safe to say that web servers is one of the most common (and ironed out) uses of parallel code. And since you are able to split up much of the processing into multiple discrete threads, more cores actually does benefit you. This is one of the big reasons why shared hosting is even possible. If server software like IIS and Apache couldn't run requests in parallel it would mean that every page request would have to be dished out in a queue fashion...likely making load times unbearably slow.

This also why high end server Operating Systems like Windows 2008 Server Enterprise support something like 64 cores and 2TB of RAM. These are applications that can actually take advantage of that many cores.

Also, since each request is likely has low CPU load, you can probably (for some applications) get away with more slower cores. But obviously having each core faster can mean being able to get each task done quicker and, in theory, handle more tasks and more server requests.

Adam Haile
+3  A: 

Mark Harrison said:

I don't have much experience with IIS, but I imagine the same scenario applies with its thread pool.

Indeed - more cores = more threads running concurrently. IIS is inherently multithreaded, and takes easy advantage of this.

Greg Hurlman
+2  A: 

Thanks guys! I was kind of expecting that, but when you suddenly have to spend money that isn't yours on something, doubts start to appear.

Michael Stum