PHP configured as CGI or Apache?

For a vbulletin forum, should PHP be configured as CGI or Apache?

 

Apache module.

PHP as CGI isn't very efficent. PHP as a CGI, and every time a request comes in, the PHP interpreter would have to launch, read/compile/execute the script, then spit out the result and shutdown.

Run it as a module, then if you can install a cache solution you'll be golden for server loads

 

Is this information right or wrong?

PHP as CGI is more secure then PHP as Apache

PHP as Apache is faster then CGI, but less secure.

I read that from an article that is several years old. Does it still apply to todays modern server configurations?

 

I'm honestly not sure, I couldn't find much information regarding CGI vs Apache modules for PHP thats not 3-5 years old myself.

Though I have read that php-cgi is more secure, but is 18-30% less efficient, so I guess its a give take situation, and is up to you. I don't have a clue of where to look to see if there is a comparative site that shows the security flaws found in each version.

(Personally, I'd go with Apache module, and then worry about security as much as possible)

 

You can Google it and see some pretty decent arguments.

In a nutshell, PHP as Apache is going to give you better performance. However, it's more difficult to secure as you run PHP with the same privileges as Apache, which is not a good idea in a shared environment. It's not a big deal if the Apache server is dedicated to a single website. As with anything, any server is only as good as its security regardless of the software used.

Apache as CGI is common because it enables you to do things like run multiple versions of PHP, and enables you to run PHP as the user and not as Apache. (Which makes for a much more secure shared environment.) It's a good bit easier to secure, as well.

Which setup you choose pretty much depends on your hosting environment. PHP as CGI is necessary for shared environments I would submit, and is really not going to decrease initial performance. However, once you get up their in traffic, the performance of PHP as Apache will be worth it.

 

If you want security and speed, you need to use what is called "FastCGI".

It allows you to reuse processes the same as if you were using the Apache module or IIS' ISAPI implementation. Spawning the CGI process is where you lose performance over an Apache Module. This gets around that step. So you get the speed of a module without using a module.

However these are spawned processes that do not have to use the same user as the default webserver user. This gives you the security of CGI without the resources used in spawning processes as much.

You can read more about FastCGI on PHP's website and it is actually the recommended installation method, especially if you decide to use IIS and not Apache.

 

Absolutely!

This is a 50/50 statement. While it may (at times) be more secure, php as CGI can NOT handle symlinks, nor can it handle php values in .htaccess code. There are other things that it can't do as well, and it's just very messy.

I get that security is an issue (it's a big, big issue), but you also have to take usability into consideration as well. This is one debate that will never be settled easily.

 

Right but then you just use a custom php.ini in the directory and that addresses the .htaccess issue pretty easily. symlinks are an unfortunate downside, but I know loads of developers that don't really have an issue with that particular problem. There are workarounds and it's not really that messy, IMHO.

As you said though, this debate will never be easily settled. There are merits to each method, and FCGI certainly improves upon PHP as CGI.

 

FWIW, I'm the resident WIMP Developer on my dev team, and running PHP using FastCGI (as Wayne said) hasn't presented any performance issues when compared to our live server which has PHP running as an Apache module.