Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I wrote the article you refer to. The below is my view on your questions, unless you are setting up a shared hosting environment.</p> <ol> <li>Neither, if you wish to use APC. Suhosin: I believe Suhosin's support on modern versions of PHP is shakey, if it is available at all.</li> <li>Neither, if you wish to use SUexec or SUPHP. If you are using PHP-FPM APC is reliable and widely used, I have no experience with Xcache. APC is EOL, as PHP ships with it's own opcache starting in (I think) 5.5.<strong>*</strong></li> <li>If you are going to use CGI, stay away from plain CGI, and use either FastCGI, or PHP-FPM.<strong>*</strong></li> </ol> <p><strong>*</strong> While you can use APC etc. with FastCGI, you will use a fair amount of memory compared to the same set up with PHP-FPM, also, if you want use the APC user cache, it's generally ill-advised to use anything other than PHP-FPM or mod_php. Using APC etc with plain CGI is just a no go.</p> <p>Some background:</p> <ul> <li><a href="http://www.php.net/manual/en/install.fpm.php" rel="nofollow">PHP-FPM</a>: PHP FastCGI Process Manager.</li> <li><a href="http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html" rel="nofollow">mod_fastcgi</a>: Third party Apache module used to communicate with PHP-FPM.</li> <li><a href="https://httpd.apache.org/mod_fcgid/" rel="nofollow">mod_fcgi</a>: Official Apache FastCGI implementation, the last time I checked it could not do what was needed to use PHP-FPM in Apache 2.2.</li> </ul> <p>Overall, I would say avoid plain CGI, FastCGI was developed to make up for the shortcomings of CGI, and PHP-FPM was developed to make the most of FastCGI.</p> <p>My 2c: If any of the sites you wish to host are in anyway mission critical/income/client related, I would say that with your current level of expertise I would recommend either going with a managed server, or at least a pre-installed and configured stack. I don't want to be a scare monger, but if as much as a day or two of down time cannot be absorbed without possibly serious repercussions, it's much better to hand off the stress to the relevant company when something goes wrong.</p> <p>If you do decide you want to do it all yourself, I would say you need to gain some experience in: </p> <ol> <li>Putting together, and tearing apart your chosen OS on an offline server.</li> <li>Running a live server for a while with personal or 'play' sites.</li> <li>Be able to troubleshoot, fix and reconfigure most of your config from memory, under pressure.</li> <li>Security. Servers, and sites do get hacked.</li> <li>Backup, backup, backup. In the worst case you may be reduced having to restore backups from somewhere other than your server, to somewhere else, and change where your DNS points to.</li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload