We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

He talks about some of the efficiency gains that memcache and nginx can give you pretty easily and some of the common uses for nginx, including using it as a reverse proxy. He talks some about Apache's typical request handling and shows the difference between that and how nginx does its "never block, finish fast" handling. He fits in the other pieces - PHP-FPM, memcached and APC - showing how each of them offers their own types of performance gains for different areas of the application.

I was originally going to write a blog post about why NginX with FastCGI was faster than Apache with mod_php. I had heard a while ago that NginX running PHP via FastCGI was faster than Apache with mod_php and have heard people swear up and down that it was true. I did a quick test on it a while back and found some corresponding evidence. Today I wanted to examine it more in depth and see if I could get some good numbers on why this was the case. The problem was that I couldn't.

He uses a "hello world" script as a baseline to do some testing and the ab to run the numbers. His results show a pretty significant difference between the two setups and an "strace" on Apache showed a clear "winner" as to why it's slower (reading the .htaccess file). Once he turned this off, though, Apache jumped up and started performing better than Nginx.

This all makes sense. mod_php has PHP embedded in Apache and so it should be faster. If you're running only PHP on a web server then Apache still seems to be your best bet for performance. And if you are seeing a significant performance difference then you should check if AllowOverride is turned on. If it is, try moving that into httpd.conf and try again.

Ran into this issue when setting up a new VPS for AutoRidge. This happens when using Nginx and PHP-FPM with PHP 5.3+ and the Suhosin patch when trying to run a PHP script using a PHAR package. From what I can gather, the Suhosin patch basically blocks PHP include/require functions from executing files ending with .phar, which results in a PHP segfault that leaves no trace of any error at all.

His solution is a pretty simple one - edit the "suhosin.ini" file to allow for the opening of includes in phar files (suhosin.executor.include.whitelist). You can find out more about the Suhosin security tool on the project's website.

We are using APC cache very heavily in our projects and during project deployment the cache must be flushed and warmed up. A common solution to warmup the APC cache is to fetch some special page via HTTP which does the job. The problem with this approach is that it's not reliable enough when PHP is served via several fastcgi back-ends.

To solve the problem, he uses a PHP-FPM module to work with the FastCGI socket and execute any file (as permissions allow, of course). In his case, he uses it to "warm up" his APC cache for the user. A code snippet is provided as an example.

This is another wonderful setup that I've found myself using rather than the traditional Apache & mod_php setup. [...] Ngnix, unlike Apache, doesn't actually load PHP. Instead, it hands it off as a proxy to a "php handler" which acts like an Application Server. So nginx by itself won't serve PHP files, but just static files.

He briefly introduces Nginx and PHP-FPM for those not familiar and points out that this combination is very fast, even without much configuration. The packages are installed with the aptitude installer and minimal changes are made to the php-fm and nginx configuration files (mostly to set up whatever your domain/virtual host is).

In this tutorial, I'll show how to build a server capable of withstanding a front-page Digg placement, step by step. This will mean your business stays online when it's most important-when everyone is looking. We'll go through the process of building a super-fast, bulletproof custom web server for WordPress. The technology stack we'll use is Ubuntu, nginx, PHP-FPM, and MySQL. In a future article we'll look at adding memcached to the mix to take performance even further.

He walks you through the full install of each piece of software (on a linux-based system) even helping you compile PHP 5.3. There's some examples of configurations and a few shell commands you'll need to get things linked together and working, but the overall process is pretty quick and painless. Even if you already have a WordPress site, it's not too hard to follow along and drop it right in.

[These technologies] 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.

He talks about setting up the PHP-FPM instance with a custom compile, adding in an init script (from the fpm branch on the PHP svn), installing Nginx and configuring them both to work together. He also helps you set up a sample site (and virtualhost) that will run the PHP-FPM stuff on each request.

PHP just added the FPM patch to their 5.3 branch, making it likely that PHP 5.3.3 will support the FPM SAPI. The FPM SAPI is an improved fcgi SAPI that allows for more advanced configuration than the original fcgi SAPI. One of the most useful features is process management, which makes it very useful for lightweight webservers, such as nginx, that does not handle process management of fcgi themselves.

There's only a few commands you'll need to get this new package installed and working with your local nginx install with the help of the emerge and layman tools. He also includes the configuration change you'll need to make to the nginx config file to get it working as a FastCGI module.

You may be asking, "What is PHP-FPM, and why should I care?" PHP-FPM is a patch for PHP core that handles the starting, stopping, and restarting of FastCGI processes as needed. This is important because nginx can only interface with PHP via FastCGI, unlike Apache, which loads the whole PHP environment right into itself.

Right now, the only downside to setting up the FastCGI interface with nginx takes a bit more work than the normal mod_php Apache handles so well. The PHP-FPM patch helps with some of this by making the FastCGI support directly embedded into PHP, removing the need for a lot of external setup.

PHP-FPM is "deciphered" as "PHP FastCGI Process Manager" and is a patch for php to greatly improve FastCGI SAPI usage in production. It adds a bunch of additional features to php's fastcgi such as: easy php-process daemonization (with ability to specify uid/gid/chroot/log-file), safe php-processes restart (without losing requests), custom error-handling and accelerated file-upload support (requires additional support from web-server).

You can find out more about the project from its main site including a FAQ and documentation to get it up and running.