... and I'm going to go try to power up the new board on the bench now so that I know it isn't DOA

...aaaaand it's alive.

BIOS settings done so I don't have to do that later.

I'm only RoHS compliant if I've had enough sleep.

oh, it's in service, just as a development box. Gonna work on it tonite too.

We may start a bit late. Got hungry. Stopped at DeSha's.

I was planning on getting into architecture details in a future blog post. Can't type that fast on this Treo...

All done now. Started late, but still did it in just under 30 mins

Tu dou: How did you design the site's web architecture layout? Which loads are the load balancers handling? Are there cache servers? Is there a network file system in place for storing images? Did you replicate or cluster the db? Which storage engines did you go with (federated, innodb...)

The About Fark didnt give much info on what Fark's running on.

:)

That's kinda on purpose -- makes it harder for script kiddies.

Short(er) versions, backwards:

- InnoDB, with some MyISAM for tables (small ones mostly) that are generally readonly

- Just one DB box -- obviously a pretty beefy SCSI-based one (especially after tonight's mobo upgrade). This single point of failure is one I definitely need to address this year, along with maybe finally testing Postgres. There are actually a few replication slaves but they're for hot backups only (one's offsite) or the dev box and production webservers don't query them

- local copies of html/images instead of one NFS copy. Disk is cheap, html changes only every few minutes, images far less than that, and rsync (over NFS) works well enough for now. NFS performance tuning's kind of a black art...

- no Squid. Static content gets served from memory by way of the box having a crapload of memory and letting the OS's disk cache do the grunt work (which would not happen w/ NFS), plus all the webservers got memory upgrades this week. Local disk tends to get hit mostly for writing logs.

- it doesn't look like it from the way the site behaves, but all 5 webservers are exactly identical (including the hardware), and they all handle all the different hostnames. So "the forum servers are slow" doesn't actually make sense as forums.fark.com is the same 5 boxes that are handling www.fark.com and img.fark.com and everything else at full speed even when the forums are sucking mud. (Separate Apache/lighttpd instances bound to separate IP's on the same box; some have more/less modules enabled than others; saves tons of memory vs a monolithic config.) It just means they're sucking mud for some reason other than CPU :)
This is a little different than most people where they have one farm of img servers, one farm of cgi servers, etc. There's pros and cons to each approach obviously

- I'm leaving out hardware details (for now) because I farking hate Intel vs AMD fanboy flamewars. (Or PC vs Mac, or Windows vs Linux, or ATI vs nVidia...)

- I am hoping to merge everything (except images) down to just www.fark.com and (www.totalfark.com) by frontending everything with a proxy. I've got some other projects higher in the queue than that. I hoped the load balancers (Foundry) could have done it but they implement it a bit differently than I'd like and it requires turning off another feature I need.

We run FreeBSD.