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 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.
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: http://boomshadow.net/tech/fixes/fixperms-script/
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.
|Low CPU usage||✔||✔|
|Low Memory consumption||✔||✔||✔|
|Runs PHP as site owner instead of Apache||✔ |
only w/ suEXEC
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.
*taken from http://boomshadow.net/tech/php-handlers/