Using suexec and suphp enforce a different type of privilege separation than the default.
The default is to separate the user's permission from the web server. That is, the user owns the files, and he has to grant the web server permission to view and change them.
The suexec/suphp model is that the webserver (when running scripts) runs under the user's account, so the website has permission to do anything that the user has permission to do. To a certain degree, this removes the separation between the user and the webserver, but in exchange it enforces a DIFFERENT separation: that is, between the website of one user and the website of a different user on the same box.
By default, PHP always runs under Apache's user account, so one website's PHP scripts can access any files that another site's PHP scripts can. Therefore, if one account on the server gets hacked, the infection can spread to the others. SuPHP prevents this.
Neither suexec nor suphp will affect the way apache serves static content. All the old rules still apply. Instead, suexec and suphp change the account under which CGI and PHP (respectively) will run. Suexec makes CGI executable run under the owner's account, while SuPHP makes PHP scripts run under the owner's account.
Suexec and SuPHP aren't necessarily better. They're just different. They won't prevent a website from being hacked (and arguably might make the site easier to hack), but they will prevent a compromise on one site from spreading to all the others. To the site administrator, this isolation is arguably more important, which is why some shared hosting systems make suexec and suphp the default.
One extremely common "gotcha" is that SuPHP checks the ownership and permissions of a script before it runs, and will return a 500 error if the permissions aren't appropriate.
In particular:
- The owner and group of the file must match the website owner (as setting in apache configuration)
- The file must not be world-writable
- The parent directory must not be world-writable
Running PHP via FastCGI will certainly give you the most flexibility. Not only can you safely use an mpm-worker Apache, you can even use another webserver altogether (e.g. nginx).
But even when staying with Apache, "PHP via FastCGI" is at the moment not one option, but at least two: mod_fastcgi, mod_fcgid. On top of that, you can either use dynamic, static, or external FastCGI processes; with or without suexec. And then there's PHP's internal FastCGI process manager, which is now replaced by the very nice PHP-FPM in PHP 5.3. All those options have different pros and cons and can lead to different problems.
Given the choice, I would pick mod_fastcgi with PHP-FPM at the moment, mostly because it allows for extremely versatile and stable setups.
Best Answer
PHP-FPM is a patch for PHP to provide some advanced process management features which are useful when used in its FastCGI variant. On a side note, PHP 5.4 will probably include PHP-FPM out of the box (according to Antony Dovgal).
Since mod_fcgid doesn't support externally spawned FastCGI servers, you need to use mod_fastcgi or mod_proxy_fcgi.
Google found this two-part tutorial (Part 1, Part 2) which describes the configuration of Apache httpd, suEXEC, mod_fastcgi, PHP-FPM and APC. I haven't tried the tutorial but it should give you an idea of how to configure it.