While the hardware speed is a consideration, it is not the sole consideration. Those accessing the server will do so over a network that will not tax ANY of the above. That said, more memory, more ramdisk possible, this is much faster than any ssd.

SSD, while improved, still has long term reliability issues and, if borked, nearly impossible to retrieve any data after failure.

Spinning rust, legacy, has a good track record and most are more than capable of handling any traffic encountered.

Which leaves: What makes more sense for your work load, expected visitors, and simplicity of maintenance? Parts do break down, which offers the least difficulty in getting back on line the quickest?

There's also that pesky budget ... what is reasonable for the task at hand?

From personal experience I've had three mission critical SSD failures and have sworn off the devices for anything other than a boot drive, and toward that I keep a mirror SSD ready to pop in if necessary. However, my really critical outfacing stuff relies on tried and true, at the highest level possible, with no less than 16gb ram (this last replacement, prior it was 32gb ram on a much slower system).

Thank you tangor, for your precious answer.

SSD, while improved, still has long term reliability issues

That hasn't been true for several years. SSD is the standard for new server racks.

The 2 data centers where my sites reside both use SSD exclusily and offer documentation on the significant speed increase.

One of the considerations has to be the type of date being served (read/writes). What i mean is a database is likely to have different requirements to relatively simple code. How much is being read and, importantly, written, to the SSD/HD.
In my experience, RAM is more useful, however, SSD can be fast.
Also, it's worth considering the server loading.
I'm sure we'd all go for the fastest affordable, but reliability is critical in some applications.

The inconsistent reliability of early SSD technology has nothing to do with today's SSD. I did a lot of research when looking for a new datacenter last year. Almost all of the newer racks use SSD.

I never had any issue with SSD so far, never broke any (but I never broke any HDD too).

One of the considerations has to be the type of date being served (read/writes)

In my case mostly read. I know, that, in that case, the cache from the OS is doing great, and that data are read directly from memory. However, I do serve lot of images too, so I don't know if the 16 GB of RAM can be enough. This is why I like (2), but my worry is , would this Xeon lag on HTTPS encryption. It doesn't feature AES instructions. But in the other hand, the W3520 is announced to be able to encode 117,600 MB/s (whereas the I5 can do 2 millions MB/s). I am far from sending 117K MB/s :) Also, for mobile users, I use the chacha algorithm instead of AES based ones, in that case, I wonder if the I5 and its higher frequency performs better. I know this is certainly a matter of micro optimization, but still.

Heh heh! My local Microcenter has a different experience on CONSUMER GRADE SSD. The stuff run in datacenters is a different breed -- and if one pays the money, one gets the results desired :)

Sure, consumer and server grade SSD are not the same, both are adapted to their usage. Server grade SSD are made to be much more robust. Same for HDD. I wouldn't be surprised that some small hosts are using consumer SSD.

I can't make my mind if the W3520 can be too much limitied when it comes to HTTPS encryption compared to the I5-2300

What are you afraid of here? Or expecting in terms of handshakes per second?

Even my Raspberry Pi 3, which has an ARM processor, can sign 80+ 2048-bit RSA's per second, per core. My old Mac Mini has a duo core T7200 @ 2 GHz, slower than the W3520, and signs 300 per second, per core. That's about 3 ms per sign. My ~$5/month virtual private servers can do 550+ per second (if you choose a good provider, you'll get modern CPUs). I don't know what prices you're looking at for those boxes, but a 4-core VPS with 160 GB SSD storage and 8 GB RAM will only cost you about $40/month.

Full handshakes are a little slower, admittedly, so you'd have to double those times, but even at 150-250 shakes/sec, you're still looking at only ~5ms per handshake. That seems pretty acceptable to me (and you can minimize the effect with session reuse, HTTP/2, etc).

Thank you robzilla, this was exactly the kind of information I was looking for.

Sorry to butt in. @Dimitri these offers you are quoting in your first post, sound like Kimsufi ones. Did you take one of these servers? I am considering getting some of their servers too, so if you have some feedback to share, they will be welcomed.

By the way, I think (3) is the most interesting. I avoid HT CPU since ressources are shared within cores. I prefer straight real cores. And 16GB of RAM can handle a pretty good amount of cached data. (running under Linux I guess)

ps: what is too bad is that, all these CPU are good, but old, meaning they do not embed AES instructions. So for HTTPS this might add some latency, depending of the volume of tragic and length of data to encode . (it's not the same encoding an HTML page or streaming videos through HTTPS)

In all cases the intended audience, the amount of traffic, and the content delivered is your calculation--and what your budget can afford. In the real world all of the above seem pretty capable as none are bleeding edge tech. :)