Written by Joe B on October 20, 2012
Recently, I’ve had to make a decision about where I want my long term hosting services to go. I was challenged with constructing a secure, fast and scaleable hosting solution that will be with us for the duration. Of course I had to decide on hosting provider and software to do the job.
I also wanted to stand out from shared hosting services, so I started making bold decisions on what software to use, one of which was replacing tradition Apache web server software with Nginx, a newer and of course, less known web server.
So, what were my reasons for choosing Nginx? Well, the 3 main reasons are as follows…
2. Speed: Because of this Event Driven Architecture, Nginx stores web sites in the RAM once a connection has been made, making a very fast experience for users browsing websites hosted here. Since the web server is only processing the request once, it no longer needs to do it again, unlike process driven web servers. This means Nginx can do other things rather than repeating the same tasks over and over.
3. Resource Management: Nginx manages the server resources much better. Coupled with a good Linux OS, Nginx has a low memory footprint. It will remove any dormant information in the RAM blocks to replace it with new information. Although this creates a delay with websites that haven’t been requested for a while, once it has been requested – the ram blocks are restored and the delay is still minimal.
Although this is brilliant, it’s not been without it’s faults in my experience. However, the issues that I faced were easily overcome with a few small configuration tweaks.
1. The PHP-FPM FastCGI Wrapper Nginx, unlike Apache, doesn’t come with a PHP-Mod by default. Instead it needs a wrapper to parse PHP scripts. If you are running a server with multiple sites on it, I recommend you use PHP-FPM sockets to limit the resources each site uses. When I first started using this, I wasn’t doing that I was allowing all available resources for each site. The servers memory was getting compromised which caused crashing. Using all memory for each site will cause a serious memory leak. Use a socket, specify the resources. Here is a generic example I have been using for each site which seems to work well. Make sure these are included in your PHP-FPM per site conf
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
2. Permalink Rewriting Nginx has a different way of rewriting URL permalinks. If you are used to Apache, you would use the lovable Mod-Rewrite and write regular expressions in .htaccess to specify arguments for URL rewriting. Unfortunately, Nginx does everything you need that Apache does, but has a different method. Instead, Nginx uses Location Directives specified in the .conf file. After a little while of getting frustrated on how to use them, eventually they become easy. This is a small price to pay for a highly optimised web server.
Here is an Nginx Directive example for WordPress that will rewrite your URLs like Apache Mod Rewrite.
if (!-e $request_filename)
rewrite ^(.+)$ /index.php?q=$1 last;
In conclusion, I have decided to use Nginx in both my live and development environments as it’s default web server. It performs excellently and is easy to maintain. It is scaleable and lightweight. It is fast and memory efficient.
This hits all the right buttons for me and I hope that Nginx developers and contributors keep up this fantastic work.
blog comments powered by Disqus