Which PHP mode? Apache vs CGI vs FastCGI

Posted on by Jake

There are multiple ways to execute PHP scripts on a web server. We’re often asked about the difference between these modes, so here it is!
We offer the three most common PHP handlers across our Linux Cloud Hosting range:

  • Apache module
  • CGI
  • FastCGI

Each of these has its own advantages and disadvantages.

Apache Module (mod_php)

Using mod_php to execute PHP scripts on a web server is the most popular method used by our customers and until recently was the default mode we set when you create a new webspace.

When using mod_php the PHP interpreter is embedded in each Apache process that’s spawned on the server. This way every Apache worker is able to handle and execute PHP scripts itself removing the need to deal with any external processes; unlike CGI or FastCGI. This makes it very useful for sites that are ‘PHP heavy’ where lots of requests are likely to contain PHP code (such as WordPress, Drupal, Joomla, etc.) because all the requests can be handled by Apache.

As the interpreter is started along with Apache, it allows it to run very quickly as it can cache certain information and doesn’t need to repeat the same tasks each time a script is executed.

The downside to this is that the footprint for each Apache process is larger as it requires more system resources with the PHP interpreter embedded. Even when serving static content such as images, text and style sheets where no PHP code needs to be executed, the process still contains the PHP interpreter.

Pros

  • PHP code executed by Apache.
  • No external processes required.
  • Very good performance on PHP heavy sites.
  • PHP configuration settings may be customized within .htaccess directives.

Cons

  • Makes each Apache process footprint larger – meaning more RAM used.
  • Loads PHP interpreter for non-PHP content.
  • Files created by PHP scripts are usually owned by the web server so you cannot edit them via FTP later.

CGI

Executing PHP scripts with a CGI application is the legacy way of running applications on a web server, it’s highly inefficient and rarely used. It was originally introduced in the 1990’s but was deemed to be too inefficient to use on anything other than very small sites.

A benefit of running applications on CGI is that it keeps the code execution separate from the web server, which allows for some added security benefits. For example, a buggy or insecure PHP script executed via FastCGI cannot corrupt or affect security of any other files outside of the domain it’s hosted on. It also means that the PHP interpreter is only called when required, thereby allowing static content to be served solely by the web server.

The inefficiencies of running PHP with CGI support spawn from requiring a new process to be created each time any PHP code needs to be executed. As you can imagine, on busier sites or PHP based applications it can be very resource intensive.

Very few Layershift customers use this mode, and we don’t recommend it!

Pros

  • Better security than mod_php (above) as PHP code execution is isolated from web server.

Cons

  • Legacy way of running applications.
  • Very poor performance.

FastCGI

FastCGI was introduced as a middle ground between the PHP Apache Module and the CGI application. It allows scripts to be executed by an interpreter outside of the web server and includes the security benefits of CGI but doesn’t include any of the inefficiencies of CGI.

When executing PHP scripts with FastCGI each request is passed from the web server to FastCGI via a communication socket. This allows for much greater scalability as the web server and the PHP interpreter can be split into their own individual server environments if necessary. However a similar end result can also be achieved using nginx in front of Apache (such that nginx handles basic requests itself and only passes dynamic requests to Apache) so this point alone doesn’t determine the ideal choice for a given scenario.

In a Plesk environment, FastCGI is executed as the domain FTP user and is the default PHP handler we offer on all our Linux services running the latest versions of Plesk Panel.

The downside of running PHP with FastCGI support is that any PHP directives defined in a .htaccess will not be used. As a workaround, it is possible to set PHP directives on a per domain basis with a custom php.ini file on any Plesk Panel server.

Pros

  • Improved security as PHP code execution is isolated from web server.
  • Static content will not be processed by PHP interpreter.
  • Allows files to be managed by your FTP user without altering permissions afterwards.

Cons

  • Cannot use PHP directives in .htaccess. This is expected by many popular scripts.
  • Requires PHP requests to be passed from web server.

Which Should I use?

On smaller sites, it usually comes down to personal preference when deciding which mode of PHP support you want. We often see customers that are running CMS applications (such as WordPress, Drupal, Joomla, etc.) tend to prefer FastCGI as it allows FTP and PHP scripts equal access, meaning file upload and edit functionality within the CMS works as advertised without any special file permission configuration.

This is only an overview of a very complex and in-depth issue. I have presented some of the main considerations to inform your decision, but each site is unique so please contact our support team if you need further guidance. For a guide detailing how to change the PHP handler using Plesk, see our accompanying knowledgebase article.