Just get plenty of memory. Nothing else matters in a modern server--CPUs are way faster than they need to be, disks are bigger than necessary (generally), and the bottleneck is pretty much always going to be RAM.

Memory is important, but I wouldn't skimp on the CPU. In my experience (a rails app on mongrel/nginx and a php5 app on lighttpd/nginx), CPU has been the bottleneck, not memory. It's also a lot easier to add memory than to increase CPU power.

I can't imagine how that could possibly be true without pathologically CPU intensive code. But, all things are possible in an infinite universe, so I won't argue too strenuously about it.

I just haven't seen any web service situations in the past seven years, or so, where CPU was the bottleneck, and I've been involved involved in a lot of web scalability projects (it's what my previous company specialized in).

Are you sure you weren't actually seeing some kind of thrashing triggered by being low on memory or too-slow disk access? For example, when Squid gets overloaded, CPU usage spikes up to nearly 100%--but increasing the speed of the CPU does nothing to make things go faster. You have to give it more memory and more disk throughput. The reason it looks like a CPU usage spike is because the select or poll loop is so busy waiting for file descriptors to be ready (not an entirely accurate description...but it should give you the gist of it if you've ever done any concurrent programming in C without using threads). But maybe PHP and Ruby can work the CPU in pathological ways that I've not seen...modern CPUs are just so damned fast, it's hard to imagine.

The universe isn't infinite. If that'd be the case, there'd be infinite matter, and therefore infinite gravity, and we'd all be reduced to black hole singularities :-)

In that case, I guess it's impossible for CPU to be the limiting factory in this universe. ;-)

(And, technically, there is still debate about whether the universe is infinite or not. And, our universe may yet reduce to a singularity. Just because it hasn't happened yet, doesn't mean it won't. The universe is tricky like that.)

No.

[Matter could still be finite in an infinite universe. And even with infinite matter flying around - gravity gets weaker with distance.]

Agreed. And to make the most efficient use of your memory don't run Apache. It's significantly less efficient with memory usage compared with something like nginx or lighttpd.

No web server at all is even more efficient. (That's my bitchy way of saying: Apache is the most powerful and flexible web server, and also the most popular. There are more reasons to run it than there are reasons not to run it. But if the reasons to run it don't apply to your deployment, then by all means, run a smaller web server.)

Learned this neat trick from the EngineYard guys. If you plan to scale, I would recommend having seperate Xen slices for your web, app, and database components. It was a life saver to be able to just move your database and app servers to seperate boxes when we needed to scale out.

Memory is critical. Yes, Rails is a little slow but application servers are trivial to scale. The database is virtually always going to be the hard bottle neck so you're going to want plenty of memory.

I'm not sure, but there was a PDF from EngineYard recommending a layout right? using XEN a many different vps for dns, mysql, etc?

Yes.

Do you have the .PDF?

Sorry! I've just found it.

http://www.slideshare.net/vishnu/xen-and-the-art-of-rails-de...

I will go for XEN, virtualization is always good and nowadays the performance lost is unappreciable, on the other side you gain a machine you can copy and move. If you have your full machine image backuped and you screw something on it, you only need to go the real shell and restore it. Also, you can have a develpment vm and a production vm, well you know better what you need.

On the hardware side setup a RAID either hardware or software, but with a hardware RAID you better pray for it to not crash. I've seem some nasty issues with raid controllers. Also, get plenty of memory and dual/quad core processor.

For the OS, I will go for Debian or Ubuntu Server if you want some kind of support (yes, I know that there are people servicing Debian support, but they are less blamable!)

I tend to think of virtualization as a sandboxing method instead of a deployment method. I'd only use virtualization if the apps I'm running may compromise the security or stability of the host machine. Otherwise, most web frameworks have some kind of deployment method, as well as support for different environments (production/test), and that's generally good enough.

It really depends on what the server is being dedicated to.

Xen and any other virtualization comes out of your overhead costs, unless you have a specific need for it (like being able to migrate seamlessly to EC2) don't bother.

For what you are planning to do Ubuntu server edition would probably cover most of your needs and give you enough support to quickly resolve problems.

Don't bother with softraid, if your data isn't important enough for you to afford a dedicated RAID controller and the disks to go with it; you can live with the possibility of losing everything up to the last backup (you will be taking backups).

I disagree on the soft RAID vs. hardware RAID (if by soft RAID, you mean the md layer in Linux). I'm not a fan of hardware RAID, in general. I wrote the following ages ago on Slashdot in response to the same kind of disparaging statement about soft RAID:

The data integrity benefits are still present, as are some performance benefits in some circumstances (in fact, Linux RAID is demonstrably faster in some workloads than a top end Adaptec hardware RAID controller, though this is the exception rather than the rule)

That said, I hate pretty much all RAID controllers (whether software or hardware). Linux software RAID means that I can drop the disks into any PC and access the data. Every RAID controller from Promise, Adaptec, and Tektronic requires me to use their disk format, and if I lose the controller I lose the data until I can get another controller. Sure, in high availability environments, you keep a spare...but with Linux software RAID, every PC in the office is a spare controller. That's my kinda redundancy. I've even had two identical Adaptecs with different firmware lead to pretty massive data loss during a server migration. Thankfully there were good backups. I've never had similar problems moving Linux software RAID disks into a new Linux box.

If you're going to be using PHP then I would strongly recommend finding a host that will let you install Fedora 7/8.

I had to set up a PHP environment on 64-bit Ubuntu recently and it wa s a major pain. The PHP binary from apt-get was 5.1.2 and pdo_mysql wouldn't install out of the box (I had to comment out part of the install script). The lighttpd binary was also pretty old (1.4.11 I think) and had a bug specific to Ubuntu/Debian that caused major performance problems with fastcgi; I had to build the latest version from source. It's still workable but it just seems like Fedora is a lot more PHP-friendly.

I would like to share this about XEN and Deploying Rails.

Very Interesting.

http://www.scribd.com/doc/69623/RailsConf07-Notes-Xen-And-Th...

unless you are pushing the virtual to the max I would just stay with that. I have used both and to be honest there is nothing in it when it comes to running web apps. I have done gaming servers on both and dedicated have the edge just. I would save your money.

Thanks everybody for the great feedback! :)