This blog will be moving to a new server very soon. If all goes well, you shouldn’t notice a thing. But just in case, I figured I’d give a warning, so that if you try to visit and you get an error, or the site won’t come up, you’ll know to just come back again later instead of thinking that my site was an early victim of the 2012 apocalypse or something.
I’m doing more than just moving onto a new server though. I’m moving to a new hosting provider, and I’m reconfiguring many aspects of how my services are set up. If you’re interested in the technical nitty-gritty, read on.
Some of you might recall that a little over a year ago, I moved from my original hosting onto Slicehost. I am now moving again, to a service called prgmr.com. I’ve had no problems with Slicehost, but the pricing for prgmr.com is lower, which made it possible for me to expand from 2 servers to 4 servers for less money.
Slicehost VPS hosting is pretty no-frills. You get a server with an initial OS installed on it, and a web-based management tool with some DNS tools and a Java applet console. With prgmr.com, it’s even more no-frills, because the console isn’t web-based. It’s SSH all the way, baby. It’s not for everybody, but it suits me fine. And even though I have more servers, it reduces my monthly hosting costs by about 40%. That said, I’m also reducing my virtual CPU power and disk space a little bit, and Slicehost has multiple facility locations, which might be factors for someone else shopping for hosting. For me, the ability to afford more servers was pretty high up.
So, that said, let’s look at what I’m changing in my setup, and why I felt it was important to move up to 4 servers.
All along, even before Slicehost, I have had trouble dealing with traffic spikes on my web server. I’ve used WP Super Cache and W3 Total Cache. I’ve used XCache for PHP code caching, and for my WordPress object cache. I’ve configured Apache to set caching headers for static files using mod_expires to reduce requests. But I still get load and memory spikes that grind my server into dust. That shouldn’t happen with only 200 visitors per hour (granted, a page view can generate about 50 HTTP requests). Obviously, I’ve configured my server poorly.
Like many large PHP applications, WordPress can be a bit hungry for memory. So when it fights against MySQL and an in-memory object cache for resources, things can start to get dicey. And of course, I’ve got a few other things on the server. When I get hit by a traffic spike (popular article, spammer runs, errant search spiders, etc), memory goes away fast. The machine starts to swap, things get slow, load average spikes as processes begin to wait for resources, and it all snowballs. I’ve got some homemade scripts that keep an eye on things and attempt to restart various services in order to force things back into line, but it’s a pretty heavy-handed way to deal with the problem.
In my new setup, here’s what I’m doing to fix it:
- I’ll be running Apache, MySQL, and Memcached all on separate servers, instead of together on one host.
- I’m switching from the Apache pre-forking model to the threaded worker model.
- I’m switching from mod_php to FastCGI (mod_fcgid) and php-cgi.
There will probably be other tweaks, as well, but those are the biggies. I’m expecting this new setup to handle waaaay more requests than the old one. Oh, and I’m definitely open to any pointers from performance tuning gurus. Please share links and tips!
When the switch-over happens, there might be a period of transition while the DNS changes propagate. I don’t plan to post again until I’ve moved this blog fully to the new host. So you’ll know it’s happened when a new article appears here.
19 Responses to Server Reconfig