I stuck this blog, alongside with a few other blogs on SgBlogging, on Slicehost one year ago. As a virtual private server (VPS), it’s supposed to be a fast service. It still is now, but I’ve been facing problems getting sites to stay stable on the VPS that we were on.
Apparently, the Apache server software was choking on the file serving part. That’s through no fault of its own, because I installed the entire kitchen sink into the program so that it could serve PHP pages natively, using the mod_php plugin. However, doing so caused each worker process for Apache to be quite plump, which by itself wasn’t a problem. Until you place the whole set-up onto a VPS with only 256 MB RAM.
To make matters worse, the operating system software running on the VPS is a natively 64-bit architectured beast, which fattens up all the processes running on the server a little bit more. It came to a point that the Apache settings had to be severely throttled to curb the number of processes it spawns, which in turn limited the number of pages it could serve at any one point.
Now, if the whole setup were to be serving just this blog (which by itself is quite light on the processor), I wouldn’t have any problem. The problem came because one of the blogs I’m hosting on the same server was littered with PHP includes and required lots of processing power. Approximately 9 times more, to be exact. All those plugins for Wordpress don’t automagically process themselves, you know? So it ended up that the web pages for that blog took a heck of a long time to load, which in turn uses up the available processing power, and deprives the other blogs of their chance to be served.
So I thought, why not try out a lighter server software, to reduce the load on the server? If it was still possible, I could also jump onto a 32-bit architecture for the server itself, so that I can use less RAM! A few months of intense research led me to this serving engine called “nginx”. It consumed barely any RAM in memory, and yet can dish out lots of pages every second. Because it was devoid of the kitchen sink (which for the most part I do not use anyway), it was so lithe and nimble.
However, that meant I wouldn’t be able to run PHP on nginx like I could on Apache. And I needed PHP in order for the server to be able to host Wordpress pages! It’s the classic case of having your cake but not being able to eat it. Fortunately for me, the adventurous nature of the open-source community meant that there were many people whom were in the same dilemma before I did. Which in turn meant that somebody must have already solved the problem.
And my deduction wasn’t wrong. A Google search turned up solutions varying from proxying data from nginx to Apache, to using FastCGI to run the PHP parser. Of course, since I was researching the whole thing in order to avoid Apache in the first place, there’s no prize for guessing what set-up I eventually went with!
Long story short, I purchased a VPS from Linode, and experimented with setting up my own server configuration. It was tough going for me, but thoroughly rewarding. I succeeded on my second try, which is why you’re seeing this post right now.
So why is it so much faster now? First, I made sure that all the blogs on the server had the maximum amount of caching turned on. Especially the bulky Wordpress blog that started it all
. Next, I made sure that the server we’ve got is located closer to Singapore, since most of the dudes reading the blogs are mostly from Singapore. That meant getting a server in the west coast of the United States. It was in itself a significant improvement over Slicehost, which was situated in St Louis. This reduced the lag from the server to users from Asia.
Another improvement was the usage of a central pool of FastCGI instances to serve the blogs. It’s less secure in that a particular user could write a malicious script to read the contents of another user, but since I know each of the people hosted on this server personally, witch-hunting isn’t exactly hard… if it ever came to that. Doing so has improved the efficiency of the whole set-up.
In the end, I finished my configuration with 200 MB of free RAM left over. It just stood around, with absolutely nothing to do. Linux used that for caches and buffers, essentially making good use for it; but after a day of stress-testing the whole set-up, and finding that it was rock solid, I went ahead… and installed Apache.
Yeah, the kitchen sink. But surprisingly, because Apache is not meant for regular Wordpress parsing, it had less baggage, and the result was that I still had 200 MB of free RAM. I configured Apache as a back-end server, with nginx waiting the tables up in front. This instance of Apache is only concerned with dealing with the SVN service (yeah, nginx couldn’t do it; but that’s the reason why it’s so fast, right?), so I cut the Apache’s settings to the bare minimum.
End result: 200 MB RAM free, a server load of approximately 0.1, and happy blog owners on SgBlogging. Kudos to Linode!
Scribbled under:
General