Transition to LEMP
If you’re reading this, it means you are using the new AFdN server! As part of my foolish reason plunge in to Virtual Private Servers.
I’ve been able to migrate all the files moved over1, setup, and fine tune the new system.
It’s not that I wasn’t happy with BlueHost, just that I had grown out of Bluehost, which makes sense: Bluehost really is targeted and people new to web hosting. I’ve had a web site since I was 11.
I’ve heard rumors that Bluehost has over 500 users on each one of their boxes, upgrading to their Pro Package a couple of years ago put me on a box with “80% less accounts per server”, but it still wasn’t cutting it. I needed more!
The LEMP setup: Linux, Nginx2, MariaDB, PHP-FPM.
From a hardware standpoint, fremont is a NextGen 1GB Linode Virtual Private Server (VPS), powered by dual Intel Sandy Bridge E5-2670 processors each of which “enjoys 20 MB of cache and has 8 cores running at 2.6 Ghz” and is shared with, on average, 39 other Linodes.
Linux
I’ve chosen to run Debian 7 (64 bit); it’s a Linux distribution I trust, has a good security focus, and I’m also very familiar with it.
Setting it up the Linode was easy. I decided against using StackScripts because I wanted to know exactly what was going into my system and I wanted to have the experience in case something goes wrong down the line.
I took a fresh copy of Wheezy (Debian 7) and then used the following guides:
I very seriously considered encrypting the entire server, but decided against because ultimately the hardware was still going to be out of my physical control and thus encrypting the system was not an appropriate solution for the attack vector I was concerned with.
Nginx
I’ve always used Apache to do the actual web serving, but I’ve heard great things about Nginx and I wanted to try it. Since I was already going down the foolish path, I figured that I had nothing to lose with trying a new web server as well.
To make things easier, I installed Nginx from the repo instead of from source and then configured it using the (more or less) standard approach.
It’s really simple to install, I probably over thought it.
rtCamp has a really great tutorial on setting up fastcgi_cache_purge that allows Nginx to cache WordPress data and then purge and rebuild the cached content after you edit a post/page from WordPress dashboard or approve a comment on an article.
MariaDB
The standard tool for web-based SQL databases in my book has always been mySQL. But just like Nginx, I’ve heard some good things about MariaDB and figured why not. The great thing is, MariaDB is essentially a drop-in replacement for mySQL. Installing from the repo was a piece of cake and there really is no practical difference in operation…it just works, but better (in theory).
PHP-FPM
PHP FastCGI Process Manager (FPM) is an alternative to the regular PHP FastCGI implementation. In particular, it includes adaptive process spawning, among other things, and seems to be the defacto PHP implementation method for Nginx. Installing from the repo was a piece of cake and required only minimal configuration.
I originally used the TCP Sockets, but found that UNIX Sockets gave better performance.
Fine-tuning
Getting everything moved over was pretty easy, I did some benchmarking using Google Chrome’s Network DevTool and using Plugin Performance Profiler from GoDaddy3.
Most of the fine tuning was the little things, like better matching the threads to the number of cores I had available. I also enabled IPv6 support, which means that AFdN is IPv6 compliant:
Enjoy faster and better access to AFdN!
0at least for AFdN, there are other sites I run that are still in migration ↩
pronounced engine-x, the “e” is invisible ↩
I know, I’m just as shocked as you ↩