Portal Home > Knowledge Base > Apache > Choosing Apache PHP handler


Choosing Apache PHP handler




An Apache handler, in general, defines the action to be performed when a file is called. An Apache PHP handler defines the method that Apache uses to load and deliver the PHP libraries. Each handler delivers the libraries through different files and implementations and each implementation affects Apache’s performance.

If you take a look at WHM > "Service Configuration" > "Configure PHP and suEXEC", you can see you have the option to choose the PHP handler Apache uses.

The available options are suPHP, DSO, CGI and, if enabled on the server, also FastCGI. The CGI option is generally not recommended, so we will focus here on the choice between suPHP, DSO and FastCGI.

When choosing between these options, it is important to note that there is no single universal answer for the question which method is better than the other. It really depends on your specific needs and the way you intend to use your server, such as how many users will have access to the server. The following comparison may help in making a decision suitable for your specific needs.

suPHP (mod_suphp)

Using the suPHP PHP handler is among the most flexible and secure ways of serving PHP requests. With the suPHP handler selected along with using the suEXEC option, all PHP scripts will be executed as the user that owns the script, instead of running as Apache's "nobody" user. For every PHP request that is being processed a separate PHP process will be spawned, so it makes it very easy to see and track if one particular user on the server is running a lot of PHP scripts, or which users are causing more CPU intensive PHP script executions.

The main benefit of using the suPHP handler is that it isolates one user on the server from the others. So if one account was compromised because of an exploit in one of your PHP scripts, the attacker would only be able to view or modify files owned by that particular user. It's also among the easiest to use with CMS such as Wordpress or Joomla. As typically these applications require the ability to create files on the server, and being that all of your files are owned by just one user, permission management is easy to configure.

The main disadvantage of using the suPHP handler is that PHP websites could be slower due to the additional overhead of having to run a separate PHP process per request. Also if your server receives a high volume of PHP requests in a short period of time, this could lead to a heavy load on your server from all of the concurrent PHP processes. Finally you won't be able to change PHP directives directly from a .htaccess file, you would instead need to make these changes in a php.ini file.

You might choose suPHP as your PHP handler if you have multiple users on your server, you don't want to worry about setting permissions, and you aren't having any performance issues with the PHP scripts that you currently run.

DSO (mod_php)

Using the DSO PHP handler is the fastest way to serve PHP requests. The DSO handler runs PHP as an Apache module. All PHP scripts are executed as the Apache user "nobody", which allows for faster execution, but can be more of a headache configuring permissions for.

The main benefit of using the DSO handler is that it doesn't have much overhead, so it's fast out of the box. You can also use PHP opcode caching along with DSO to speed up your PHP requests even further. Additionally you can set PHP directives directly via .htaccess files to control certain functionality of PHP.

The main disadvantage of using the DSO handler is that all PHP scripts will need to be owned and excuted by Apache's "nobody" user. In order to work with DSO, you will basically need to continuously change the ownership of all files and directories under the public_html directory of the hosting accounts to have the ownership of user "nobody". You will need to do that after you have uploaded new files not via PHP script (or whenever files change their ownership to anything but user "nobody"). If you won't do that, at least to PHP files, you will have permission issues when Apache won't be able to write to these files. The requirement to change the ownership to user "nobody" also means that PHP executions can't easily be tracked on a per user basis since they're all run from the one web server user. It is worth noting that using DSO with MPM ITK eliminate the need to use "nobody" as the user. However, since this comes with a downgraded performance, it somewhat defeats the purpose of using DSO in the first place, so it might be better to use DSO with user "nobody" without MPM ITK.

If you have multiple users on the server, another drawback of the DSO handler would be security. Because all of your users on the server are having their PHP scripts executed by the same "nobody" user, if one of your sites is exploited due to a flaw in one of your PHP scripts, the attacker could potentially look at or modify files outside of that user's directory that had the PHP script that was exploitable. So when using the DSO handler it's always very important to keep all of your PHP software up to date with any security patches so they are not exploited.

You may want to choose DSO as your PHP handler if you only have one user and your primary concern is speed and performance. If you don't intend to allow other users/entities to access hosting accounts on your server, but you know you (and perhaps your employees) are the only ones who will have access to the server, it might be a good idea to choose DSO for the speed and performance benefits.

FastCGI (mod_fcgid)

With FastCGI (mod_fcgid) you can use suEXEC just like with suPHP to allow PHP scripts to be executed by the user of the PHP script instead of using the Apache "nobody" user. FastCGI doesn't require a single PHP process execution per request like suPHP does, so it can be faster and can reduce CPU usage by holding PHP scripts in memory.

The main disadvantage of the FastCGI handler is that it can be very memory intensive. This is because FastCGI keeps PHP sessions opened in the background in memory for quicker access and the ability to use PHP opcode caching can add to the memory usage as well. Additionally FastCGI can encounter an array of errors depending on how your PHP scripts are coded.

FastCGI is not recommended for use by cPanel. Although it's faster than suPHP, it can create many stability issues on the server (therefore it is not enabled on WHM by default).



Also Read

Powered by WHMCompleteSolution