Server load can be a hard thing to deal with especially when, in my case, your peak loads occur during only six days of the year. The server will hum along for the rest of the year without issue, no indication of the impending and inevitable doom just around the corner. Then your server gets Slashdotted, or in my case the Nike Outdoor Nationals happen.
Last year I migrated the NSSF server to a VPS with 512megs of RAM. VPSs are a great option for someone wanting some of the benefits of a dedicated box (root access, set it up as you see fit, etc) but doesn’t want to pay ~$250+ a month for the dedicated hardware.
But with the great freedom of a VPS or dedicated box comes new issues you used to not have to worry about on a shared/managed host.
During the last two meets we’ve been running into a problem — the high load of people refresh-monkeying for results and photos of their kids for two days was making the server choke (80k+ pageviews a day; nothing amazing but certainly not a light load for a single-server operation). At the first meet in March I spent the weekend learning about Apache optimization for high load and updating the server’s configuration to meet the swarm of parents and track enthusiasts descending upon our server. Of course the optimizations were bounded by the need to run within 512 megs of RAM, along a MySQL instance. We survived the storm, but the site’s response times weren’t ideal under that load.
It wasn’t until the second meet, held last weekend, that I got to realizing that maybe the solution wasn’t in tweaking Apache, but rather ditching Apache. Now don’t get me wrong, Apache is great and has been my server of choice for six years, but it is a beast. Apache is meant to do everything and because of that isn’t ideal for low-memory-footprint environments that come under heavy load. Yes, more RAM would help, but I’m not the kind of guy that just throws more hardware at a problem when I can do something to fix it. Open-heart surgery, not a band-aid that comes attached to an additional monthly fee, was in order.
I’d heard of Lighttpd before; the servers at Meebo run on it. It’s a very lightweight server that has a small footprint and runs wonderfully under very high loads. So during the first morning of the two-day meet, when Apache was crying in a corner just wanting people to leave it alone, I went about installing Lighttpd.
Within 30 minutes I had Lighttpd ready to go, hooked up using FastCGI for PHP, with the main site running within it on a test port. Usually one doesn’t switch things like this during peak traffic, but desperate times… I flipped the metaphorical switch and shut down Apache and brought Lighttpd up in its place on the public port.
Wow.
Even with only minimal tweaking to the configuration the difference in page response time was comparable to night and day. It felt like the server was under normal load even though we were at our peak traffic for the year! Plus the server went from 80 megs of RAM open with Apache running to 140 megs (which later went up to 200 megs with more tweaking) open with Lighttpd running. Small footprint indeed. A few more minutes of work and I had all the other domains and subdomains back up as well.
Lesson learned: don’t be afraid to switch from the norm. Sure, Apache is pretty much the standard when it comes to a LAMP server, but that doesn’t mean it’s what you have to stick with. In this case Lighttpd had what I needed most: performance, and it didn’t require me sacrificing any functionality I’d come to rely on with Apache.
Next Entry
Moving From Apache to Lighttpd »
Previous Entry
« Trek
