Know about PHP handlers

PHP handlers determine how PHP is loaded on the server. In order for a site to run on PHP, 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. 
There are multiple 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 impacts Apache’s performance, because it determines how Apache serves PHP.
It is essential 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 better than another; it depends on your unique setup.
Note: In the event that your server runs multiple versions of PHP, you may assign different PHP handlers to each individual instance 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 takes only 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. You can do this via the EasyApache script of WHM.

List of PHP handlers

DSO
Also known as mod_php.  While this is an older configuration, its main benefit is speed. It is generally considered the fastest handler. It runs PHP directly from Apache, without having to pass it to a separate service for processing.  This means that PHP scripts will run as the Apache user, which by default on our servers is the user ‘nobody’.
DSO has two things to consider before switching to it.  First, any files that need to be written to by the webserver have to have write permissions for the ‘nobody’ user, and any file created by the webserver will be owned by ‘nobody’.  Websites that need to upload files through PHP may run into permissions issues, since the settings aren’t as clear cut as the other handlers.  This is common with WordPress users that upload files through the WordPress interface or utilize the auto-update feature.
A special note about the above: it is a common misconception that files need to have the 777 mode to be writable. This is not true, and generally a bad idea since it means the files are writable by anyone. To make a file writable by the webserver, the highest permissions needed should be 664 and owned by ‘user’ and group ‘nobody’. For directories this would be 775 and user:nobody. This should be enough to allow the webserver to write to the location without making it writable by everyone and introducing a potentially critical security vulnerability.
Also, know that DSO offers a different type of security as opposed to suPHP/FastCGI.  Since the server runs it as ‘nobody’ anyone that would be able to exploit a file on your server to gain elevated privileges will have access to any other file that the webserver can directly access. What this simply means is that an intruder could have access to files across multiple accounts, but only those files that are owned by ‘nobody’. Please see the Security section below for more information.
The main advantage of DSO is speed and resource usage. With opcode caching extensions like eAccelerator or APC installed, DSO will run significantly faster and at a lower footprint than the other handlers. It is also the default setting on our servers.
A good rule of thumb is that DSO is best for servers that are running one or two large, high-performance websites where efficiency and speed are a concern.

CGI

CGI handler will run PHP as a CGI module as opposed to an Apache module.  The CGI method is intended as a fallback handler for when DSO is not available.  This method is neither fast nor secure, regardless of whether or not suEXEC is enabled. ServInt therefore does not recommend using CGI.

suPHP

suPHP runs PHP as a separate service that then passes the compiled code back to Apache for serving. It is technically a CGI module, however it is much different than the CGI handler mentioned above. The main difference, and the advantage of having suPHP, is that with suEXEC enabled it runs the PHP scripts as the user calling them, rather than as the ‘nobody’ user. For example, if an account is owned by the user Spock, all instances of Apache serving that user’s website will run as user Spock. The advantage here is that it makes tracking down websites using excessive resources easier.
Another advantage of running the process as the user is that it simplifies the overall permissions scheme. The webserver will be able to write to files that are owned by the user and not just ‘nobody’. What this means in the long run is that auto-update/install features in many CMS solutions will work more easily, and the general permissions of your file/directories is more clear-cut: 644 and owned by user and group user for files, and similarly 755 and user:user for directories.
The security difference between suPHP and DSO is that suPHP confines an intruder to the particular user that he/she has affected. The exploit can’t cross accounts, however it can affect every single file the user owns as opposed to just the files writable by the webserver. Please see the Security section below for more information.
The main disadvantage of suPHP is speed and CPU load. suPHP runs much slower than the other handlers, and you will see significant increase in your overall CPU load when switched to it. suPHP also cannot work with an opcode caching extension such as eAccelerator or APC, which is part of the reason for the increase in CPU usage. Because of this, it is recommended that you implement a caching plugin if you use this with a CMS, such as W3-Total-Cache for WordPress. This handler is recommended more for the smaller reseller client. This is because it locks down exploits to one affected account, and the CPU load increase will not be that significant with less busy sites or small number of individual cPanel accounts.

FastCGI

FastCGI (aka: mod_fcgid) is similar to suPHP in that it is a separate process that compiles the PHP which is then sent back to Apache. It is also a CGI module, which means with suEXEC enabled PHP runs the process as the user. This allows you the same permissions advantages of suPHP mentioned above. The difference between the two, however, is how they control the PHP processes. suPHP runs each time a PHP process needs to be compiled, whereas FastCGI keeps persistent connections open that can be recalled by the same PHP process. This allows you to use an opcode caching extension such as eAcceleartor or APC with it to increase performance.
The drawback is FastCGI has a high memory usage.  Due to the persistent connections mentioned above being stored in memory, you are going to see much more available memory being taken up by FastCGI.
A good analogy of FastCGI and suPHP is to think of a book with several chapters. With suPHP, this book will have no table of contents and no index, so each time you want to find something you have to look through the book to get it. This takes time (increased CPU usage) and is slow. With FastCGI, this book has an extensive index and table of contents, so you can quickly and easily find what you are looking for; however these additional pages make the book much thicker  (increased memory usage).