<< there's no place like 127.0.0.1

This is one of the most common topics that I see customers will ask about. As highly important as PHP handlers are, they often the least understood. They seem complicated, but its not too hard to understand. You don’t have to know that exact science of how it all works, but one should learn the basics if you want to take your website seriously. Picking the right PHP handler for your website will give you the optimal speeds you want and maybe allow you to save some money by using a cheaper hosting package. So I invite you to take a few minutes and learn something new.

What are PHP handlers

In order to run a PHP site, the server must interpret the PHP code and generate a page when visitors access the website. It interprets the code based on which PHP library you are using, such as PHP 4 or PHP 5. A PHP handler is what actually loads the libraries so that they can be used for interpretation. PHP handlers determine how PHP is loaded on the server.

There are multiple different handlers that can be used for loading PHP: CGI, DSO, suPHP, & FastCGI. Each handler delivers the libraries through different files and implementations. Each file and implementation affects Apache’s performance, because it determines how Apache serves PHP.

It is critical for your server’s performance that you select the handler that fits your situation. Selecting the right handler is just as important as the PHP version itself. One handler is not necessarily always better than another; it depends on your unique setup. What caching do you need, what modules do you need, etc…

Note: You may assign different PHP handlers to different versions of PHP. For example, version 5 may be handled by CGI while PHP 4 is handled by DSO.

How to change the handler

Changing the handler on cPanel is very easy to do and only takes seconds. Log into WHM and navigate to: Main » Service Configuration » Configure PHP and SuExec

You simply select your PHP handler choice from the drop-down menu. Then hit “Save New Configuration”.

Note: If you do not see your desired choice in the drop-down menu, it may need to be compiled on the server first. Run an “Easy Apache” to compile it.

List of PHP handlers

DSO (mod_php)

DSO is also known as mod_php. DSO stands for: Dynamic Shared Object. This is an older configuration but is generally considered the fastest handler. It runs PHP as an Apache module. This means that PHP scripts will run as the Apache user, which is the user: ‘nobody’.

DSO has two drawbacks. First, all files created by a PHP script will have the ownership of ‘nobody’. They will not be readable from the web. Websites that need to upload files through PHP will run into file permission issues. This is common with Wordpress users that upload files through the Wordpress interface or utilize the auto-update feature. These will fail with DSO.

The second drawback is a security issue. Created files will have the ‘nobody’ ownership. If a hacker finds an exploit in your PHP script, they could implement a file that has the same privileges as important system files that are also owned by ‘nobody’. This will give them the ability to modify files outside of that user’s account. This is really bad for anyone who does reselling or simply is hosting other person’s sites. You would not one user to be able to affect another user. However, if there is only one account on the server (or if all the accounts are yours), then DSO may be right for you. The speeds benefits of DSO are unquestionable.

An easy way to prevent the hack issue is to always keep your site’s software up to date. Check with your PHP script’s developer to keep up on the new releases. If you are the only one being hosted on the server, this is easy to do as it’s part of your webmaster duties already. However, if you’re reselling, it would be unreasonable to expect all your user’s to keep their software up to date. They simply may not be as diligent as you.

DSO’s low CPU usage typically amounts in higher speeds and load times over most other handlers. It is also the default setting on most servers.

CGI

CGI stands for: Common Gateway Interface. The CGI handler will run PHP as a CGI module as opposed to an Apache module. CGI still runs PHP processes as the Apache ‘nobody’ user. However, if you have suEXEC enabled, it will allow you to see the user that made the request.

The CGI method is intended as a fallback handler for when DSO is not available. According to cPanel’s own documentation, this method is neither fast nor secure, regardless of whether or not suEXEC is enabled (http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/MorePhphandlers).

suPHP

suPHP stands for Single user PHP. suPHP also runs PHP as a CGI module instead of an Apache module. It differs from CGI in that PHP scripts that are called from the web will run under the user that owns them, as opposed to ‘nobody’. suPHP is typically the default handler and is recommended by cPanel for serving PHP because you will be able to see which user owns the account that is running the PHP script.

suPHP is beneficial in that if you are using a file upload tool on your site (such as an automatic updater or theme/plug-in installer for Wordpress), the files will already have the right ownership & permissions. Uploading and other Wordpress functions will not work without suPHP or FastCGI.

suPHP also offers a security advantage that any php script that is not owned by the particular user (such as another account or root) will not be executable. Also, files that have permissions set to world writeable will likewise be non-executable. This means that if one account is compromised, the malicious scripts will not be able to infect other accounts.

The drawback is that suPHP generally runs a much higher CPU load. In addition, you CANNOT use an Opcode Cache (such as Xcache or APC) with suPHP. It is strongly recommend that you install a caching plug-in to supplement this ned. If you find that your server is still continually struggling with CPU usage, you will want to consider switching to DSO or FastCGI.

If you DO switch to either suPHP or FastCGI, you will need to update the file permissions and ownership. See my other article for automatic fixperms on cPanel servers.

FastCGI

FastCGI (aka: mod_fcgid or FCGI) is a high performance variation of CGI. It has the security/ownership benefits of suPHP in that PHP scripts will run as the actual cPanel user as opposed to ‘nobody’. The difference with FastCGI is that it can drastically save on CPU performance and give speeds close to that of DSO. It can also be used with an opcode cacher like eAccelerator or APC, which can help further speed the loading of pages.

The drawback is FastCGI has a high memory usage. This is because rather than creating the PHP process each time it is called, like suPHP, it keeps a persistent session open in the background. This is what lets it work with an opcode caching software.

If you like the security/ownership benefits of suPHP and you can afford a major increase in memory usage (meaning you already have a low average memory usage), you may wish to consider using FastCGI.

Comparison Table

  DSO CGI suPHP FastCGI
Low CPU usage    
Low Memory consumption  
Runs PHP as site owner instead of Apache user  
(only w/ suEXEC)
Good security    

Special Note for Wordpress Users

If you are using Wordpress to run your site, please consider the following:

  • Functions that require uploading files to the server (such as Auto-updates or Plug-in/Theme installation) will NOT work unless PHP is loaded as a CGI module. This means they will ONLY work with suPHP or FastCGI. This will ensure they are uploaded with the correct ownership & permissions.
  • CMS platforms such as Wordpress will notoriously run a high CPU load. You will want to install a caching plug-in such as WP Super Cache, especially if you are running suPHP. If you find that your server is still continually struggling with CPU usage, you may want to consider switching to DSO or FastCGI.

Note about this article

This article is one I had written and shared with the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. They are using my article with my permission.

Change Log

This post has been updated since it’s original publishing. Here is a list of changes:

  • 01/09/13: Rewrote some parts to alleviate confusion
  • 02/12/12: Added some more definitions
  • 02/02/12: Link clean up
  • 10/06/11: Better explanation for CGI with suEXEC

Running Gitit Wiki with Upstart

I know I've been rather quiet lately. I've been busy travelling for a little bit and found myself at a new job. Well, now I'm getting bac...… Continue reading

Installing ImageMagick & PHP Imagick

Published on March 26, 2015