Dec 072012
 

This is an article of mine first published on Wazi

PHP is a widely-used language, it offers general purpose scripting that is well suited for Web development. It can be embedded into HTML, and is compatible with all major operating systems such as Linux, many Unix variants, Microsoft Windows, Mac OS X, RISC OS and more.

It works with most major Web servers and it’s the scripting engine of many popular software such as Wordpess, Drupal, phpBB, mediaWiki, Joomla and Moodle just to name a few.

A thing that not everyone know is that you have different choice to run PHP on your Server, the most common option is the one used in the LAMP stack(Linux+Apache+Mysql+PHP): mod_php, this is the more common way to have php working with your web server, but is not the only one and for someone is the worst in terms of performance, other options available are PHP-FPM (FastCGI Process Manager) and PHP FastCGI, another way of running a PHP script from a webserver could be ti use the traditional CGI method but for its poor performance this method is not used anymore

In this article I’ll show you the pros and cons of these different ways to use PHP with your webserver and as first thing I’ll give you a general suggestion to speed up the performance of your PHP.


PHP accelerators

PHP Accelerators also called op-codes cachers will increase the performance of your PHP applications, by caching the compiled form of php scripts.
A PHP accelerator typically reduces server load and increases the speed of your PHP scripts between 1 to 10 times depending on how many different pages/php scripts are used and cached.
My suggestion is to use APC, this is an op-code cache maintained by the developer of PHP and is planned to be integrated in PHP from version 5.4, so this make it one of the best integrated cache system for PHP.
This is in short how a PHP program is run by the Zend Engine, these are steps to go from your PHP script to the code really used by the Engine, this is commonly known as “opcodes”, representing the function of the code.

  1. The first step is reading the PHP code from the filesystem and put it into memory.
  2. Lexing : The php code inside is converted into tokens or Lexicons.
  3. Parsing : During this stage, tokens are processed to derive at meaningful expressions.
  4. Compiling : The derived expressions are compiled into opcodes.
  5. Executing : Opcodes are executed to get the final result.

The goal of APC is bypass the steps from 1 to 4, caching in a shared memory segment the opcodes generated and then copies them into the execution process so Zend can actually execute the opcodes.
APC is also really easy to install and configure, and so in general my suggestion is to use it every time you have a PHP installation.

But now let’s take a look at how you can run PHP with your webserver.

Apache + Mod_PHP

Apache remains the world’s most popular web server and the most easy way to use PHP with it is to install the mod_php package.
This package is usually present in the repository of any Linux distribution such as Centos, Debian or Red Hat and so installing and managing it is really easy and this is the main reason under the success of this method of running PHP.

With Mod_PHP the PHP interpreter is kind of “embedded” inside the Apache process : there is no external PHP process called by Apache, which means that Apache and PHP can communicate better, the configuration of this module is really easy and is usually embedded into the Apache main configuration, the problem that you could see with this software is that the mod_php is loaded by any single Apache child and so a bigger process is used also for serving static resource such as image files, css or javascript.

Another “problem” of this method is that it works only on Apache, usually this is not an issue as Apache is the more complete Web server you can find, but website that run on small VPS or big site that have to serve million of pages at day could search for a different Web server solution that can scale up or down better than Apache, and so once they have to choose also a different way to run PHP.

mod_php:

Pro:

  • Easy to install and Update.
  • Easy to configure with Apache.

Cons:

  • It Works only with Apache.
  • Make every single Apache child bigger (memory wise).
  • Needs a restart of Apache to read an updated php.ini file.

FastCGI PHP

FastCGI is a generic protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI’s main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.

FastCGI can be used with many web server, there is a mod_fcgid for Apache for an easy integration, but it can be used also with other popular webserver such as: Lighttpd, Nginx, Cherokee or even IIS.

With FastCGI is possible to set up set up multiple versions of PHP, this is particular useful when you have old website made for PHP 5.1, and that are not compatible with the latest version of PHP, with FastCGI you can serve with an old PHP this website, while using the latest version for all the others, this is not possible with mod_php.

FastCGI also utilize suexec to support different users with their own instances of PHP. It reduces the memory footprint of your web server, but still gives you the speed and power of the entire PHP language.

FastCGI:

Pro:

  • Compatible with many web server.
  • Smaller memory footprint than mod_php.
  • More configuration options: multiple PHP or suexec

Cons:

  • Require more configuration than mod_php.
  • Less known in the IT.


PHP-FPM

This is the newer flavor for using PHP with a webserver only in mid-2009, the developers changed the format of PHP-FPM to be more modular, and no longer be a patch that had to be applied against PHP, PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features that can be really useful both for website on small VPS and for big solution on multiple servers.

It has many point in common with FastCGI and so this solution can be used with any webserver that is compatible with fastCGI, one common combination in the web is Nginx +PHP-FPM, some features of this solution are:

  • Process Management. Ability to “gracefully” stop and start PHP workers without losing any queries. This allows gradually updating the configuration and binary without losing any queries.
  • Starting the workers with different uid/gid/chroot/environment and different php.ini options.
  • Ability to emergency restart all the processes in the event of an accidental destruction of the shared memory opcodes cache, if using an accelerator

PHP-FPM:

Pro:

  • Compatible with many web server.
  • Smaller memory footprint than mod_php.
  • More configuration options than FastCGI

Cons:

  • Require more configuration than mod_php.
  • Less known in the IT.
  • For some people this project is still “too young” and think it’s not stable

Conclusions

I cannot tell you what’s the right method for you or your company to use PHP, I’m using mod_php for his stability and the fact is so well known in big project and PHP-FPM on small VPS where saving some memory while keeping fast performance is a must. The important thing to keep in mind is that there are different solutions available in these days and knowing all of them is fundamental when planning your project.

References:

PHP on wikipedia

PHP main site

Everything you need to know about APC

Popular Posts:

Flattr this!

  One Response to “The different faces of PHP”

  1. PHP-FPM wipes the floor with the listed methods but it’s hard to use in shared environments. For that, use apache2 with mpm-itk core or suphp, but for a normal, everyday webserver PHP-FPM + nginx does a way faster work while eats predictable amount of memory. Not necessary lower,but predictable, and that’s key agrument point.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)

*