Moving a WordPress site from Apache to Nginx isn’t easy, but is well worth the effort – if you are on a micro instance and memory is at a premium.
I’ve written multiple posts about optimizing my blog to increase speed (here, here, and here)… unfortunately, my web server continues to crash at least once a day (usually due to a spike in traffic).
I started looking to stripping out unnecessary Apache modules, but had too many problems identifying the required modules for WordPress. After 30 minutes of failed server re-starts, I decided to ditch Apache all together and install Nginx as my webserver.
While Apache is the most well know WordPress webserver, Nginx is growing in popularity (WordPress.com uses Nginx on their site). In order to get a clean install, I created a new t2.micro instance, installed Nginx (and php-fpm) and migrated my WordPress files over .
There isn’t a lot of documentation on Nginx: I spent most of my time referencing the instructions at the following sites:
The install wasn’t smooth sailing. I had a beast-of-a-time getting my permalinks to work, and I forgot to change a few of my settings in my wordpress.php conf file (which caused my server to constantly crash).
There are still a few things I need to reconfigure – W3 Total Cache works differently in Nginx, so I’ve ignored it. I also have yet to re-install my certificates for https.
All that being said, my website is as fast as it was when I started my blog – probably due to Nginx, as well as the lack of “bloat” on the server (old WordPress plugins and no MySQL install).
My other call-out is that the use of AWS RDS and an Elastic IP made the most complicated parts of the migration simple.
A few simple changes to your Apache config file can greatly improve your micro instance performance.
Last week, I moved my WordPress DB from my t2.micro instance to RDS, with the hope that the change would improve my website performance (I was originally hosting both the web and DB server on the same EC2 instance). The good news is that I no longer get the “database connection” errors I was wont to receive. Bad news is that I’m still having performance problems: now with Apache.
As a stopgap, I configured an alarm to reboot my instance in case I received a status failure. This was a less-than-ideal fix; my server would reboot multiple times a day – sometimes 2-3 times in a 30 minute window!
Last weekend, I finally got a chance to dedicate time to resolving the issue. I spent most of my time looking at the threading options for Apache – prefork, worker, and event. I tried both prefork (the default) and event (which is the less memory-intensive option of the three). I ultimately stayed with prefork, with the following settings (h/t to Marjin van Deele’s post: Tweaking a AWS EC2-micro instance for WordPress).
Two days later, my server seems to be ok. Next step is to strip out some of the preloaded modules from Apache (as outlined in Hayden James’ post: Strip Down Apache to Improve Performance & Memory Efficiency).