Suphp has lots of advantages like you can customize php configuration by defining separate php.ini for all your website. And you do not have to correct the ownership of the files that are created by php scripts. And also Files or directories no longer need to have 777 permissions. This option is probably the most flexible way of serving PHP requests and is generally very secure than DSO module.
suPHP is beneficial 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.
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 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.
To summarize, if SuPHP is enabled:
1. PHP scripts executes under your user/group level.
2. Files or directories no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them to protect you from someone abusing your scripts.
3. Your scripts and directories can have a maximum of 755 permissions.
4. Files and directories also need to be owned by your user/group.
5. Using .htaccess with php_value entries within it will cause a 500 internal server error when attempting to access the scripts.
All php values should be removed from your .htaccess files to avoid the 500 internal server error. Creating a php.ini file to manipulate the php settings will solve this issue. Also eAccelerator won’t work with SuPHP because SuPHP run php as a child process under different users. eAccelerator needs all processes to be forked from the same parent to share a memory segment.