In this new post to his site Kevin Schroeder takes a look at the performance difference between Apache+mod_php and Nginx+FastCGI and why the second is noticeably faster than the second.

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.

Pavel Shevaev has a quick new post to his blog showing how to get PHP-FPM to execute PHP scripts via a socket request.

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.

On the ServerGrove blog today there's a new post from Ishmael about setting up multiple versions of PHP on one Apache instance with the help of FastCGI.

There are several reasons you might need to run multiple versions of PHP on the same server. Maybe you have a PHP 5.2 application running on your server and you need to start working on another application based on a new framework like Symfony2 or Lithium? Perhaps you haver a client with a legacy site that runs PHP 5.2, or maybe you simply want to test some of the new functionality? This post is going to explain how to setup a server to run multiple versions of PHP.

Normally, Apache can only be compiled with one version of PHP, but FastCGI gets around that by letting you define it in a configuration file instead. They also include support for defining the user the process runs as (suexec) that helps to make permissions issues lesser. Included are all of the command-line calls and config settings you'll need to make to get things set up.

Brian Swan has posted a new timeline to his MSDN blog today about the road that Microsoft has traveled with PHP to get to where they are today.

This morning I came across this article on PHPDeveloper.org: Blast from the Past - One Year Ago in PHP. That brief look into the past got me to thinking about what Microsoft has done lately toward PHP interoperability. (By "lately", I mean in the last few years.) And, I've been working on a presentation for TechEd in Berlin next month that will, in part, provide a brief overview of Microsoft's efforts toward PHP interoperability and support. So, I thought I'd share a bit of that summary here

The timeline runs from back in 2006 when PHP and Windows/IIS/SQL Server just wasn't much of an option through the FastCGI and SQL Server driver years and finally rounding out with WinCache, PHP 5.3 improvements for Windows and the Azure SDK for PHP.

On his blog today Matthew Weier O'Phinney talks about how to run mod_php and FastCGI side-by-side on a Zend Server instance.

I installed Zend Server some time ago, so I'm still on a PHP 5.2 mod_php binary. I have several PHP 5.3 binaries compiled and installed locally for running unit tests and sample scripts already -- so the question was how to keep my 5.2 mod_php running while simultaneously allowing the ability to run selected vhosts in 5.3? The answer can be summed up in one acronym: FastCGI.

He shows how to enable FastCGI in Apache (on Ubuntu), make a virtual host for your site and create a "cgi-bin" directory to contain the script(s) for your PHP versions as CGIs.

On the Content with Style blog today there's a new post showing you how to get the Zend Framework up and running with the nginx web server running PHP as a FastCGI.

Since I while I heard good things about nginx and wanted to use it for my Zend Framework MVC applications. I just got a Ubuntu server working after one of those days that seem to be a never ending Google search and debugging session, so I thought I'd share the outcome with you.

They show you how to install the needed packages, set up FastCGI and configure it to work with nginx and, of course, configure nginx to use the FastCGI. Included in the nginx config is a pointer to the Zend Framework's document root. Setting up the Zend Framework and creating an application isn't a part of the tutorial.

Because of a recent addition to the the Gentoo PHP package (FPM support) they're looking for people to test it out and report back the results. To help, Ole Markus has written up some instructions on how to get it up and working on your system with nginx.

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.

On the SitePoint PHP blog today Louis Simoneau talks about something that can potentially make the PHP+ngnix combination even faster - the inclusion of the PHP-FPM patch into PHP's core.

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.

Abhinav Singh has a new post to his blog today showing how to get Nginx, PHP (FastCGI) and XCache all up and running on an Ubuntu installation. He made the switch to this platform after he made the change in his choice of web servers:

Recently, because of a mandatory VPS move I had an opportunity to migrate all my sites from apache to nginx. My old box was in a messy state and setting up a new box from scratch was always going to be fun. Here in this post, I will walk you through all the steps that helped me migrate seamlessly. Specially, how did I setup the new box ensuring zero downtime on the sites.

One of the keys to his transition was to have no downtime in the switch between the old and new systems (managing local vs public DNS let him test). The software is all installed via the apt-get package manager and the changes you'll need to make to the configuration files are all included, making the install as easy on you as possible.

Ever frustrated by the fact that the php.ini changes to take effect in your FastCGI setup you need to either flush the current instances or just wait until they die off. You might want to take a look at the latest post from Ruslan Yakushev about the MonitorChangesTo setting that's recently been introduced.

The latest releases of the FastCGI Extensoin 1.5 and FastCGI update for IIS 7.0 have a new configuration setting monitorChangesTo that takes an absolute path to a file that FastCGI will monitor for changes. In case of PHP this means that you can set monitorChangesTo to a path to php.ini file, so that any time it is modified the FastCGI module will restart the php-cgi.exe to pick up the configuration changes.

He includes a few examples of how to use it with different versions of IIS - 5.1/6.0, 7.0 and the latest - 7.5. Configuration settings and screenshots are included as needed.