Tuning a Magento and WordPress Website

We do a lot of web site tuning, and have been since before it became the routine. A while back, we were asked to tune a Magento and WordPress installation running on a virtual machine at a budget host (see our warnings about that on our cloud providers page.). We thought it might be useful to blog about an example experience to give some idea of what’s possible as well as provide some humor with the problems we discovered.

36.08 Seconds

We’re not kidding. A product list page took a hair over 36 seconds to generate on the current installation. How’s that for a new level of usability?

The virtual machine had 800mb of RAM, and it was all gone. Digging in, we realized that someone had “optimized” the installation by putting the Magento cache and session dirs in tmpfs. Great idea, if you have a plethora of RAM – and you put finite limit on the tmpfs file system. There were 300,000 dead sessions eating up almost all the RAM on the box.

We also noted that every Apache module available in Debian was enabled and the .htaccess file for Magento had thousands of lines in it.  We don’t generally recommend Apache for performance reasons, but this configuration was abysmal.  We once again were informed that the hosting provider had “tuned” this.

Even fixing this, the site still crawled and we noted disk access times in the hundreds of milliseconds. With this and other evidence, we encouraged our client to abandon this hosting provider and move to a 1GB server at Rackspace.

5.84 Seconds

Simply relocating the installation to the Rackspace server provided an enormous performance boost; from utterly unusable to merely semi-unusable.

3.9 Seconds

Upgrading to a recent version of Magento provided another performance boost, as well as critical security fixes.  Once again the “full service” hosting provider had failed to properly maintain any of the software on the system, or even change the default Magento administrator password.

3.3 Seconds

Enabling Magento’s built-in caching shaved off another 0.6 seconds.

3.0 Seconds

Upgrading PHP to a newer version than the distribution had gave us another 10%.

2.9 Seconds

Installing and configured APC strangely provided little benefit compared to what we typically see.

2.7 Seconds

Tuning php.ini provided a small benefit.

2.5 Seconds

Migrating from Apache and mod_php to Nginx and php-fpm improved things a bit more. Note that we are only timing the actual page generation; downloading all the images, javascript, css, and other content was substantially faster with Nginx.  Server memory usage was also reduced by moving to php-fpm.

We have more work to do on this site, but an improvements from 36 to 2.5 seconds on the slowest page meant the site went from un-launchable to launched and transacting.  While we’re focusing on the worst page, the home page of the site went from 8.68 seconds to 0.34 seconds – not just usable, but quite fast!