Designing a Server

From Hexwiki
Revision as of 02:53, 12 May 2014 by Vekseid (talk | contribs) (Created page with "So, you have got yourself a domain and have picked a hosting company. Possibly an active site already - either way, you need a server, either dedicated or colocated. The CPU ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

So, you have got yourself a domain and have picked a hosting company. Possibly an active site already - either way, you need a server, either dedicated or colocated.

The CPU almost always gets top billing from every hosting company out there.

CPU power is cheap. Disk space is cheap. Memory is cheap. Bandwidth is precious.

Unless you have a specific situation that you know alleviates it, the limiting factor of your server is going to be your disks' (yes, plural) bandwidth. The more you have, and the faster they are, the better your server will perform. It should be your primary consideration when purchasing a server.

Memory should be your second consideration. RAM can help alleviate disk bandwidth, especially for platter drives. The less writing that will be done on your drives, the more memory can have an impact.

While it is possible to run into cpu-limiting situations, this is something you will generally be aware of ahead of time, and can plan accordingly. If you just want something for your website, however large, chances are the CPU will not be your problem.

RAID

My first experience with a RAID controller was when it died on my first webhost.

My fourth experience with a RAID controller went okay, but RAID 10 turned out to be barely faster than a single drive plugged straight into the motherboard, since caching was disabled, and was only 40% faster than a single RAID 1 pair.

Since my primary I/O activities were because of my databases, I could easily divide my I/O into near-equal halves. My twin RAID 1 setup was both faster and more reliable than my RAID 10 go.

What I do currently, instead of subjecting my servers to another potential point of failure, is to simply mirror all of the content onto a slave server. If my main server fries, I have an up-to-the-second backup, and can bring that backup live in a a few hours while the main server gets fixed.

I am not kidding about dividing database i/o in half, either:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.48        19.98        14.46  458222973  331670564
sdb              12.56        11.67       189.13  267644581 4336877660
sdd               4.56         1.15       402.12   26346994 9220655384
sdc              31.83       104.94       405.29 2406284973 9293350004

sda hosts my boot, root, and home partitions (which includes my websites proper), and is an SSD. sdb primarily holds logs - including the binlog, and is a 10krpm Raptor drive. sdc hosts my databases proper, and is an SSD. sdd hosts InnoDB's double-buffer, and not much else. As you can see, the write rate between sdd and sdc is nearly even.