While Netalyzr didn’t clearly show what was going on with my Internet connection it did raise a red flag about network buffers that might be the issue. Unfortunately, that’s a router configuration issue on the part of my ISP so I’m not hopeful for a resolution. But I can always gather data then open a trouble ticket with the vendor.

Regardless, Netalyzr looks like a great tool for troubleshooting connectivity issues.

(Note that I’ve included gists at the bottom of the article with the important configuration files.)

I was using a Slicehost slice with a typical Apache/mod_php configuration but there wasn’t enough memory so it would start swapping with a little use which caused frequent outages. But rather than upgrade to the next sized Slice, I found that I could double my RAM for the same money simply by moving to Linode. So that was the first change I made. (FWIW, I’m not suggesting this as a performance enhancement but it’s definitely a better value.)

Next was a series of changes, some of which were noted in the Tumbledry article, some not. The Tumbledry article was thin on details so I did the research myself and came up with a number of articles with the best being this article on setting up nginx, PHP-FPM, APC, memcached and the W3 Total Cache WordPress plugin. The cryptkcoding article shows how to setup an Ubuntu Linux system for seriously fast WordPress performance that consumes incredible few system resources.

First, an ease of use feature that I discovered: someone did a build of PHP 5.3.8 for Ubuntu 10.04 LTS. Since PHP 5.3 includes PHP-FPM, you can keep everything package based.

To use these packages add these lines to /etc/apt/sources.lst:

deb http://ppa.launchpad.net/brianmercer/php/ubuntu lucid main
deb-src http://ppa.launchpad.net/brianmercer/php/ubuntu lucid main

After updating the sources list, run this command to update the apt cache:

sudo apt-get update

(For more details on using these packages, as well as setting up a similar system, checkout this HowToForge article. In particular, there are some useful comments at the bottom.)

Anyway, one of the main features of this setup was swapping out the Apache web server for nginx and PHP-FPM. Like most PHP developers, Apache and mod_php has been the default setup for PHP applications for years. However, I can now vouch for the nginx/PHP-FPM combo as both stable and fast production environment. (I will try out this combo for development on my next PHP project to see how it works.)

Importantly, the system now uses a UNIX socket for the connection between the web and application servers rather than TCP/IP. That means that for the core application and web services there are two UNIX sockets used, one between the web server and the application server then again between the the application server and the database server (MySQL clients use the UNIX socket when the “localhost” host name is used or the host name is blank.)

Anyway, to really see the difference the architecture changes made, I used a blitz.io Rush to hammer the two instances.

First up was the old Slicehost system. This is the Rush configuration I used (same as Tumbledry):

--pattern 1-250:60 -T 4000 -r california

The result: this rendered the system completely unresponsive and required a hard reboot. Here’s a shot of “top” before the system stopped responding. Note all the memory being consumed, load on the way up and lots of Apache processes:

Oh no! The system just died:

Next was the new Linode hosted solution. The result is that the new architecture sustained the Rush with virtually zero CPU usage (I’m not kidding) or any changes to memory usage. Varnish takes most of the load.

So as it turns out, I can also serve up 9 million hits per day from a small (512MB RAM), inexpensive ($20 per month) virtual server.

Here are the important configuration files:

nginx.conf:

nginx virtual host config:

php5-fpm.conf:

varnish:

wordpress.vcl (varnish site config):

Ubuntu has included the Eucapyptus project in the aptly named Karmic Koala release 9.10 project in order for mere mortals to be able to install and manage their own cloud. Considering that some important people recommend keeping your data on your own hardware to avoid vendor lock-in and privacy issues, this allows companies to avoid the issues while getting some of the advantages of the cloud. Of course, companies will still need a team, albeit much smaller, of crack infrastructure managers but they will have the advantages provided by the abstraction of hardware and it’s associated management tools.

Besides, what could possibly be cooler than having a compute cloud in your basement data center running on a bunch of cheap PC servers? I’m sure nothing can quite compare.