PHP handlers

22 March 2021

A PHP handler is an Apache module that interprets and runs PHP code. There are a handful of handlers to choose from, and each has its advantages and disadvantages. What’s more, using the most suitable handler for you website can have a huge impact on the performance of your websites.

What handler to use depends on many variables. This makes PHP handlers a complicated topic. We are of course more than happy to work with you to make sure that your server’s configuration is optimal for your particular workload – it’s what managed hosting is all about.

PHP handlers and PHP versions

cPanel servers support multiple PHP versions, and different virtual hosts can use different PHP versions. For instance, you might have the website example.com running PHP 7.3 and a dev.example.com subdomain that uses PHP 7.4. On top of that different PHP versions can use different handlers.

The WHM interface for PHP handlers depends on the cPanel version you are using. For versions up to 86 you can view what handlers are used via Software » MultiPHP Manager. The PHP Handlers tab lists the PHP versions and their handler. More recent cPanel versions show the same information under Software » MultiPHP Manager (new). This interface has two tabs:

• System Settings shows the default (inherited) PHP version; whether or not PHP-FPM is enabled for new accounts and the PHP handler used for individual PHP versions.
• User Domain Settings lists all domains; the PHP version the domain uses and whether or not PHP-FPM is enabled for the domain.

If you prefer the command line, you can get information about PHP versions and handlers by looking at /etc/apache2/conf.d/php.conf.

Changing a PHP handler

You can change the PHP handler for a PHP version by selecting a handler from the drop-down list. The one exception is PHP-FPM, which strictly speaking isn’t a handler. To use PHP-FPM you first needs to be enable it and then apply it to one or more domains via the User Domain Settings tab.

Available PHP handlers

cPanel servers offer six different PHP handlers out of the box.

CGI

CGI (mod_cgi) is rarely used, as it’s slow and relatively insecure. There are better variations on the handler. Before we get to them, it’s still useful to understand how CGI works.

You can think of CGI as a technology that let’s a web server talk to external applications. It lets Apache interact with server-side scripting languages such as PHP and Perl. Historically, such scripts were often installed in the cgi-bin directory. When a script in the directory was accessed the server ran the script and the output was sent to the user’s browser. The cgi-bin directory isn’t required to process server-side code – servers are usually configured to treat any PHP script as a CGI script.

CGI has the following characteristics:

• By default, PHP processes created by CGI run as the user nobody. However, on cPanel servers CGI uses the mod_ruid2 module to instead run scripts as the owner of the domain. The nobody user is a so-called pseudo user. It effectively runs processes with minimal permissions. The downside of running processes as the nobody user is that it’s difficult to see which processes belong to which domain.
• CGI doesn’t let you use Apache directives in .htaccess files. You need to use php.ini files instead.
• The reason CGI is slow is that it creates a new process for each requests (and reads configuration files in the process). This makes CGI relatively CPU-intensive. On the flipside, it does mean that its memory usage is relatively low.
• CGI lacks support for PHP Opcode Cache methods.

DSO

DSO (mod_php) is not enabled by default on cPanel servers. It can be installed via EasyApache (search for “dso” under PHP Extensions). Note that you need to use the Prefork MPM with DSO.

As with CGI, you are unlikely to use the handler but it’s useful to understand its basics.

• DSO creates a new web server (httpd) process when a PHP script is executed. It lets Apache interpret PHP code and spawns child processes when needed, which reduces resource usage.
• DSO does not immediately terminate a process when it finishes. Instead, processes wait for further instructions. As a result DSO has a relatively low CPU usage.
• By default processes are owned by the nobody user. You can use the mod_ruid2 of mod_mpm_itk module to run scripts as the file owner instead. mod_mpm_itk is an Apache module that depends on the prefork MPM.
• DSO can make use of Opcode cache.

suPHP

suPHP (mod_suphp) works much like CGI but is more secure as PHP scripts are always executed with the permissions of their owner. This is particularly important on servers that have multiple user accounts. However, suPHP is no longer maintained and largely replaced by PHP-FPM.

• suPHP creates a new process for each request. Like CGI, suPHP is relatively CPU intensive.
• Apache directives can be added using php.ini files.
• Processes are always owned by the user.
• suPHP doesn’t support Opcode Cache.

FastCGI

FastCGI (mod_fcgid) is a much improved version of CGI. One of the main reasons why it performs very well is that it keeps PHP script in memory. This means it doesn’t have to start a new PHP process every time a PHP script is executed.

• PHP scripts are executed as the script owner.
• FastCGI is less CPU hungry (because it keeps PHP script in memory). However, it does use more RAM. For cPanel servers it’s recommended to have at least 2GB of memory.

PHP-FPM

FPM isn’t really a handler. Instead, it’s a daemon that takes FastCGI to the next level. It more efficiently manages processes (by using pools) and has advanced features, including a “slow log”. It’s also relatively light on memory.

The main downside of PHP-FPM is that its configuration is more complicated and that it works slightly differently. For instance, on cPanel servers error logs for users are stored in the ~/logs directory and the global error log is /opt/cpanel/ea-php??/root/usr/var/log/php-fpm/error.log (where ?? is the PHP version). Similarly, if you need to restart PHP-FPM then you need to do so either via WHM » Restart Services » PHP-FPM service for Apache or using the command /scripts/restartsrv_apache_php_fpm.

In short, PHP-FPM is an advanced and feature-rich tool. In particular high-traffic website can benefit from using PHP-FPM, but it may need some tweaking. We can of course work with you to get the most out of PHP-FPM.

LSAPI

LiteSpeed is a drop-in replacement for the Apache web server. LiteSpeed is included by default on cPanel servers that run CloudLinux and has its own control panel (Plugins » LiteSpeed Web Server). For RHEL, Centos and Amazon Linux servers you can use cPanel’s own “light” LSAPI version. The latter option is unlikely to perform better than PHP-FPM.

One of the main selling points of LSAPI is that it “just works”. It usually doesn’t involve tweaking and fine-tuning, and for end users it works as expected. For instance, you can add PHP directives in .htaccess files.

If you are switching from PHP-FPM to LiteSpeed then you need to first disable PHP-FPM for individual domain before selecting the lsapi handler.