I wanted to ask you about PHP/Apache configuration methods you know, their pros and cons. I will start myself:

---------------- PHP as Apache module----------------

Pros: good speed since you don't need to start exe every time especially in mpm-worker mode. You can also use various PHP accelerators in this mode like APC or eAccelerator.

Cons: if you are running apache in mpm-worker mode, you may face stability issues because every glitch in any php script will lead to unstability to the whole thread pool of that apache process. Also in this mode all scripts are executed on behalf of apache user. This is bad for security. mpm-worker configuration requires PHP compiled in thread-safe mode. At least CentOS and RedHat default repositories doesn't have thread-safe PHP version so on these OSes you need to compile at least PHP yourself (there is a way to activate worker mpm on Apache). The use of thread-safe PHP binaries is considered experimental and unstable. Plus, many PHP extensions does not support thread-safe mode or were not well-tested in thread-safe mode.

---------------- PHP as CGI ----------------

This seems to be the slowest default configuration which seems to be a "con" itself ;)

---------------- PHP as CGI via mod_suphp ----------------

Pros: suphp allows you to execute php scipts on behalf of the script file owner. This way you can securely separate different sites on the same machine. Also, suphp allows to use different php.ini files per virtual host.

Cons: PHP in CGI mode means less performance. In this mode you can't use php accelerators like APC because each time new process is spawned to handle script rendering the cache of previous process useless. BTW, do you know the way to apply some accelerator in this config? I heard something about using shm for php bytecode cache. Also, you cannot configure PHP via .htaccess files in this mode. You will need to install PECL htscanner for this if you need to set various per-script options via .htaccess (php_value / php_flag directives)

---------------- PHP as CGI via suexec ----------------

This configuration looks the same as with suphp, but I heard, that it's slower and less safe. Almost same pros and cons apply.

---------------- PHP as FastCGI ----------------

Pros: FastCGI standard allows single php process to handle several scripts before php process is killed. This way you gain performance since no need to spin up new php process for each script. You can also use PHP accelerators in this configuration (see cons section for comment). Also, FCGI almost like suphp also allows php processes to be executed on behalf of some user. mod_fcgid seems to have the most complete fcgi support and flexibility for apache.

Cons: The use of php accelerator in fastcgi mode will lead to high memory consumption because each PHP process will have his own bytecode cache (unless there is some accelerator that can use shared memory for bytecode cache. Is there such?). FastCGI is also a little bit complex to configure. You need to create various configuration files and make some configuration modifications.

It seems, that fastcgi is the most stable, secure, fast and flexible PHP configuration, however, a bit difficult to be configured. But, may be, I missed something?

Comments are welcome!

4 Answers 4


Running PHP via FastCGI will certainly give you the most flexibility. Not only can you safely use an mpm-worker Apache, you can even use another webserver altogether (e.g. nginx).

But even when staying with Apache, "PHP via FastCGI" is at the moment not one option, but at least two: mod_fastcgi, mod_fcgid. On top of that, you can either use dynamic, static, or external FastCGI processes; with or without suexec. And then there's PHP's internal FastCGI process manager, which is now replaced by the very nice PHP-FPM in PHP 5.3. All those options have different pros and cons and can lead to different problems.

Given the choice, I would pick mod_fastcgi with PHP-FPM at the moment, mostly because it allows for extremely versatile and stable setups.

  • 1
    >I would pick mod_fcgid with PHP-FPM This will prevent you from using APC. Only mod_fastcgi allows to use external FCGI servers (which is PHP-FPM). If you use mod_fcgid all advantages given by php-fpm will be zeroed. Jul 23, 2010 at 6:10
  • That was, of course, a stupid typo. Sorry for the confusion, I corrected it.
    – earl
    Jul 23, 2010 at 13:54

Not really answering your question, but I do not get this thing about FastCGI being difficult to configure. It is different that the other methods it should replace (mod_php, mod_python,...) so it may require rewriting a portion of the code. That can be the hard part, but for configuring Apache, at least, I find it is a cinch. As an example, I was testing a WSGI application in python, and I wanted to see how it performed with all the protocols that WSGI supports. Here is the virtual host file with the configurations for all the protocols (with mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host
#SCGIMount /
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py

It does not seems complex to me. Sure, FastCGI supports many options and it can be tweaked to death, but that is another matter.

To run is as a different user, use suexec and FastCGIWrapper, then it becomes:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py

And see this link for a custom php.ini, but you should be able to specify it with the -initial-env option, i.e.

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/
  • Yea, adding config to apache is simple. But your configuration does not allow to execute scripts on behalf of their owner or at least by specific user. Also, custom php.ini cannot be used in your case (I prefer to restrict open_basedir for each virtualhost for his directory only) Apr 22, 2010 at 9:40
  • I do not know PHP well, but those are the same issues you face with straight CGI. And you can easily run fastcgi as external server as any user you like. Apr 22, 2010 at 11:08
  • Added additional info to the answer. Apr 22, 2010 at 13:29

A good candidate is: The Apache 2 ITK MPM

apache2-mpm-itk (just mpm-itk for short) is an MPM (Multi-Processing Module) for the Apache web server. mpm-itk allows you to run each of your vhost under a separate uid and gid — in short, the scripts and configuration files for one vhost no longer have to be readable for all the other vhosts.

Has worked for one of our clients very well with hundreds of VirtualHosts with quite a lot of visitors.

You get all the Pros from running PHP as a module and sort out some of the cons.

  • Yea, but is last updated a year before. And what is even more important opens a potential security whole. "Since mpm-itk has to be able to setuid(), it runs as root (although restricted with POSIX capabilities where possible) until the request is parsed and the vhost determined. This means that any security hole before the request is parsed will be a root security hole. (The most likely place is probably in mod_ssl.)" Apr 22, 2010 at 8:14
  • The code works, is very stable and probably no reason to update it. The module got an active Debian developer (don't know about the original developer). And it's FOSS and not very complicated.
    – rkthkr
    Apr 22, 2010 at 10:08

To me, the question is what is the purpose of the web server. Is it serving more than one virtual host? If so, then you need to sacrifice performance for isolated security. Yes performance does suffer, but with today's hardware it still should take quite a bit of traffic to bring major performance issues.

If performance is that important, run the one site on a VPS or Dedicated server and configure for performance.

  • I just ask about possible variants. Not about choosing the best one. I will choose myself. Apr 25, 2010 at 11:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .