BenV's notes

As I love to tinker around with apache/php installations to get them to work as fast as possible while still keeping some security in tact, I found myself messing around with FastCGI today. But why?! Here’s why:
On this machine I previously installed suPhP to get php scripts to run as a normal unix user instead of user apache (so users have the ability to completely lock out their database settings etc for other users on that machine). However, to speed stuff up on a magento webshop I wanted to have a PHP opcode cache running (I tried out APC).
Those opcode caches don’t work very well (read: they only slow things down) if you run php the way it’s supposed to run under suPHP though, because suPHP needs to be run using php’s CGI mode. This means no mod_php, but instead starting a new php instance for every request. Not only is this expensive in terms of startup costs, but it also makes those caches completely useless. (since they can’t share any memory without resorting to state files or some sort of uglyness).

Anyway, suphp is still nice to have for simple sites that don’t get many hits or don’t need to be very fast. Therefore I wanted to have both options available. Here’s how.
I started out with the Slackware packages for php and apache, but soon found both to be inadequate. Php lacked some modules that some site wanted, and apache didn’t even bring suexec along.
However, the slackware layout is good enough so I altered the slackbuild script a bit and built my own apache. You might need to install some packages as dependencies though. For instance I didn’t have ‘expat’ and ‘db44′ installed.

Now edit the slackbuild file so it compiles with your compile flags. My changes were:
1. Changed VERSION to 2.2.14 (was 2.2.13)
2. Added these to the configure flags (to enable suexec) around line 103:

Compile and install it. Note that the suexec part requires root permissions, so I did this as root.

PHP and suPHP

Note that since php is a pleuris product it will ignore the DESTDIR variable that usually works for creating a package. If you want a nice package for php, consider using the slackware build script instead. (I was too lazy for it this time). Next suPHP:

That went smooth. PHP could learn something from this. Now we still need to configure suphp. To do this we create 2 files and alter httpd.conf a little.
First suphp.conf:

Personally I left most to default, but I did change the log path and the docroot.
Next we need to enable it in apache, but to keep module stuff in their own section we put this in mod_suphp.conf which we include in the httpd.conf.

That should be enough. Now for sites that you want to enable suphp, simply add a few lines to their vhost config like this:

Now you should have a working suPHP installation (provided that you restarted apache etc).
If something fails, check the logs, especially suphp.log and of course the apache error_log.

FastCGI

To get this running I loosely followed this blog post. It pretty much worked like Brandon explained, after I recompiled my apache for suexec support that is. Thus a summary:

Install FastCGI

Now for the magic part, enabling it in a vhost.
First we need a php wrapper script:

Note the -d apc.shm_size=64 option. This specific option is to set the cache size for APC, but this way you can give php custom settings per vhost. Neat huh? If you want to give this vhost its own php.ini you can add this to the script:

PHP will check for a php.ini in that dir. Make sure to check the permissions on these dirs though, especially on the wrapper script. Your users might do stuff you don’t want if you let them alter these things.
Finally to enable FastCGI per vhost, add something to the vhost configuration like this (make sure to disable suphp on that vhost!):

Restart apache and you should see stuff like this in the process list:

APC

Now for some speedup. Let’s see apachebench on that magento vhost without APC and FastCGI:

As you can see it takes more than a second to get the page to load. Well, 0.8s mean across all, but 2.5s per request.
Let’s install APC:

Restart apache and voila. Time for a new benchmark.

W000t…. that’s a lot quicker, almost 4 times as fast. Nice