This past weekend has been a busy one so far as Tailgrab’s back-end is concerned. The site was migrated off it’s “512” node to a “1024” as well as some architecture changes to how the site is served. The reason behind this move isn’t that the site required more resources, on the contrary, Tailgrab had more than sufficient resources on the smaller node. Rather, the move was to consolidate the resources I had between various nodes and simplify management.
The plan for this move had been in the works for a while, as I’d desired to move to Nginx as my web server in place of Apache2. The reasoning for this was an attempt to speed up the site as Nginx is known to be faster than Apache2 for static content. WordPress however isn’t static content and requires PHP for it to function, so what’s the point right? Well much of the content on Tailgrab is static content (images, js, css, etc), more over, I use a plugin for WordPress called WP-SuperCache which pre-caches all the pages on the site, both as html and gzipped html. This means that nearly the entire site can be served up as though it were static, skipping PHP for most content. There are however some remaining challenges to finishing off this transition. The use of timthumb to generate images in many places throughout the site requires PHP for every single hit. These images cannot be served statically via Nginx like normal images as Timthumb stores these images as text files in a caching directory of it’s own. Upon request for a timthumb image the request is passed to a PHP-FPM pool where it turns these text files back into the required image, each time requiring PHP to do so. Additionally, because these images have query strings in their URL, they’re not cached properly by browsers and proxies. Once I’ve removed this hurdle, the entire site should act as though it’s static and operate quite rapidly.
One of the biggest challenges in transitioning to Nginx from Apache2 is the lack of .htaccess files, or anything like them. What originally would have gone in an .htaccess file now must go directly into the sites configuration file, and Nginx
restarted reloaded for them to take effect. Rather, the types of rules that would have gone in an .htaccess file, as Nginx uses a different rule structure they must all be translated to work. This becomes a big deal if you’d originally used .htaccess files to secure directories or if you’d turned on fancy URIs in WordPress or used WP-SuperCache. And since most plugins and PHP applications assume you’re using Apache, they might spew .htaccess files everywhere and you don’t want visitors to be able to access those. This means you need an additional rule to block access to such files, just in case they exist.
Overall it was a great learning process and I’d like to think I’m a better sysadmin now because of it. Hopefully everything continues to run smoothly, and just as importantly, hopefully I’ve managed to secure everything that needed securing. *fingers crossed*