Nginx, a HTTP and reverse proxy server, known for its blazing speed in serving static files, including grand performance in terms of serving up FastCGI pages makes for a great coupling with the upcoming PHP-FPM sapi in PHP (It is currently in the 5.3 branch and previously was a patch) offer a great solution for finally getting rid of that old sloppy mod_php in Apache. Do you have the same issue where your apache instances have started to run too large? This might be the time to start to move forward.
A little background on why I have endeavored on this path. While running Apache at several jobs and institutions it simply became clear that under heavier traffic loads having all of the ridged custom components of Apache were starting to slow things down. To the point of large instances running sometimes up to 300MB in size. Having this size just to get a simple image or PHP page was just not necessary as well as proved to be a performance bottleneck.
While the first point of departure is to utilize a faster web server to proxy the existing one, it still does not stand to the point of keeping everything to a single task. This is where the FastCGI instances of PHP started to come in very useful as well as having something to monitor the processes aka PHP-FPM.
Overview
This posting assumes that you are not operating under a shared hosting account and that you have some dedicated hardware, a virtual machine or something in the cloud. Currently I have just switched from a dedicated server at The Planet to their new cloud offering which reduced my immediate costs substantially (149 to 99 per month for essentially the same thing but even better – my disk now operates off of a SAN. To you cloud junkies, you know disk speed / IO wait time is a pain in the a**. This simply mitigates these types of issues). Which has allowed me to take some time to move over to Nginx and PHP-FPM without having to have reconfigured my existing machine to what I wanted.
Further, you must be comfortable in running everything under a single user account, this is not something for a shared hosting supplier (while you can accomplish this, it is not why I am writing this post since the security of which, is just terrible). Simply put, if you have a shared hosting account switch to a VM (cloud hosting is a VM) or a dedicated server. This may not make some of you happy to hear but there are generally a large amount of issues with shared hosting – mostly related to security. But that is another rant…. Let’s get started.
PHP-FPM
PHP-FPM is a FastCGI process manager for PHP, say goodbye to the spawn-fcgi script from Lighttpd. The PHP-FPM has additional features that can make it appealing for any crowd. To name a few:
- Emergency restart in case of accidental opcode cache destruction
- Enhancements to FastCGI, such as fastcgi_finish_request() – a special function to finish request & flush all data while continuing to do something time-consuming
- Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) – Covered in the PHP-FPM workers documentation.
- Adaptive process spawning
PHP-FPM has been available for quite some time, however, it is new to the PHP 5.3 branch (to date, it has not been in a packaged release from PHP). There is a bit of configuration that you will need to do with PHP in order to get up and running with PHP-FPM. If you are afraid of compiling or not using your package managers builds, then you may want to stop reading now.
PHP 5.3 + PHP-FPM Installation
Installing PHP 5.3 and including PHP-FPM is simple. I tend to statically compile many of my extensions into PHP to make maintenance more simple with multiple machines. However, this is not a necessity. To get going follow these instructions (if you already have PHP and want to maintain some of your current configuration do a php -i from the command line and grab the configure statement – excluding apache related configuration (aka apxs). I’ve removed most of my configuration from this tutorial. You may find that you need additional librarys installed (just install them through your package manager).
Add Your Init Script
Download the script from: http://svn.php.net/repository/php/php-src/branches/PHP_5_3/sapi/fpm/init.d.php-fpm.in
Now that you have the script, modify it to contain the correct paths. I am not going to do this here since if you’re running your own server or virtual machine I feel you should know to do such things .
Update Your Configuration
The default may run fine for you, however, it is always best to take a peak at what users are running, your port numbers and ensuring that all of your items are setup the way you want them. Look for php-fpm.conf under /etc/php-fpm.conf or /usr/local/etc/php-fpm.conf. Then update this file to your liking. Once coompleted, start it up: /etc/init.d/php-fpm start – if you have issues, ensure that your variables are correct and that the configuration lines up with the init script (aka pid file for instance).
Nginx
Installation
Most of your distributions support nginx. You can install this through your package manager, however, I prefer to have the most recent versions (and running a redhat based distro that generally requires installing from source or creating a package – there is no .spec file so I took the easy way out) therefore, I decided to install from source which is a simple task but yet I customized it a bit to exclude a few things I did not need.
Steps that you will need to follow (to some degree):
- Download Nginx (we’ll use stable for now)
- Extract the Package
- Configure, Make and Make Install
Just as a note, I generally save my configuration in a shell script to allow for easy upgrading. You may want to do the same as it will allow you to quickly upgrade rather than attempting to figure out what you’re configure script was.
So that was easy, or did you take the cheater way out and just install the package (which most are at 0.6)? Either way, this should still work for you.
Many tutorials (especially the one that I looked at beginning to convert to nginx simply rely on a single index.php – not that it is an issue but be wary about these tutorials since many of them exhibit issues related to security (one of which, is the first result in Google on a search for: nginx wordpress rewrite). I’ll say a little more once we get into the Site portion of the configuration.
The Main Configuration
The main configuration file is generally in /etc/nginx/nginx.conf or /usr/local/nginx/conf/nginx.conf. Here we want to setup a few of our variables to improve the server itself. There is a great guide from Slicehost on nginx defaults, you may want to get started there. Now my configuration is based quite a bit off of the Slicehost configuration as well as a few additional changes when we get more into the PHP section. For reference here is my configuration.
One thing to note, is that due to some of my domain name sizes, I needed to increase the variable “server_names_hash_bucket_size” to 128 instead of the current default 32.
Setting up FastCGI Variables
These will be needed in order for your installation to work, as well as, setting up your environmental variables that get sent to PHP. You will notice most of these parameters.
Now in that same file, you may want to also include some additional fastcgi configuration. These will likely need to be tuned for your environment and may take a little trial and error until you find the best fit.
Setting up your First Site
Let’s configure a simple default site that just processes PHP scripts. No real hard trouble here! Create a new file in the sites-enabled directory called default.conf. We are going to have it parse our /var/www/default directory (if you do not have one, create one and add an index.php file of some sort in there). Here is a quick and simple configuration to get started:
Note the location ~ \.php$, this tells us that for every PHP file to push it into fastcgi, now if you parse additional extensions through PHP, for the sake of everything, please add extensions to the location! Otherwise your precious PHP files can be downloaded. Yes, it is a serious thing!
What Not to Do
This configuration is evil and I actually found it on some tutorial but here it is, in it’s fully glory.
See how it only pushes things to index.php? Yes, this means that no other PHP files will be parsed. WTF mate? Yes, so please do not utilize a configuration such as this unless you know the repercussions.
Non-Default Sites aka Virtual Hosts
Virtual hosts are extremely easy in Nginx, all you need to define is the server name (the same goes with subdomains). You can basically copy out the default.conf into a specific site and add in a “server_name” variable to the “sever” section followed by removing “default” from the port. You can add in aliases by simply putting a space in between the servers. Here is an example (I also cache local files for a period of 30 days since they will likely not change):
That’s just about all you need for now with Nginx, if you run into issues the nginx wiki has quite a large amount of links to get you started in the right direction with rewriting those old nasty apache rewrite rules.
Conclusion
While this posting was not as detailed as I was hoping it to be, I hope that you can see some of the items that I was attempting to address, specifically the PHP portion in ensuring that you are covering yourself when it comes to ensuring that people are not downloading your configuration. Also if you are running multiple virtual hosts, it is a good idea to ensure that they are running under separate users.
courtsy:Mike Willbanks
No comments:
Post a Comment