Quelles configurations Apache / PHP connaissez-vous et quelles sont-elles?

Je voulais vous poser des questions sur les méthodes de configuration PHP / Apache que vous connaissez, leurs avantages et leurs inconvénients. Je vais commencer moi-même:

---------------- PHP comme module Apache ----------------

Avantages : bonne vitesse car vous n'avez pas besoin de démarrer exe à chaque fois, surtout en mode mpm-worker . Vous pouvez également utiliser divers accélérateurs PHP dans ce mode comme APC ou eAccelerator.

Inconvénients : si vous exécutez apache en mode mpm-worker, vous pouvez rencontrer des problèmes de stabilité car chaque problème dans un script php entraînera une instabilité de l'ensemble du pool de threads de ce processus apache. Dans ce mode également, tous les scripts sont exécutés au nom de l'utilisateur apache. C'est mauvais pour la sécurité. La configuration de mpm-worker nécessite PHP compilé en mode thread-safe. Au moins les référentiels par défaut CentOS et RedHat n'ont pas de version PHP thread-safe, donc sur ces systèmes d'exploitation, vous devez compiler au moins PHP vous-même (il existe un moyen d'activer le mpm de travail sur Apache). L'utilisation de binaires PHP thread-safe est considérée comme expérimentale et instable. De plus, de nombreuses extensions PHP ne prennent pas en charge le mode thread-safe ou n'ont pas été bien testées en mode thread-safe.

---------------- PHP comme CGI ----------------

Cela semble être la configuration par défaut la plus lente qui semble être un "con" lui-même;)

---------------- PHP comme CGI via mod_suphp ----------------

Avantages : suphp vous permet d'exécuter des scipts php au nom du propriétaire du fichier de script. De cette façon, vous pouvez séparer en toute sécurité différents sites sur la même machine. De plus, suphp permet d'utiliser différents fichiers php.ini par hôte virtuel.

Inconvénients : PHP en mode CGI signifie moins de performances. Dans ce mode, vous ne pouvez pas utiliser d'accélérateurs php comme APC, car chaque fois qu'un nouveau processus est généré pour gérer le script, rendant le cache du processus précédent inutile. BTW, savez-vous comment appliquer un accélérateur dans cette configuration? J'ai entendu parler de l'utilisation de shm pour le cache de bytecode php. De plus, vous ne pouvez pas configurer PHP via des fichiers .htaccess dans ce mode. Vous devrez installer P ECL htscanner pour cela si vous devez définir diverses options par script via .htaccess (directives php_value / php_flag)

---------------- PHP comme CGI via suexec ----------------

Cette configuration ressemble à celle de suphp, mais j'ai entendu dire qu'elle est plus lente et moins sûre. Presque les mêmes avantages et inconvénients s'appliquent.

---------------- PHP comme FastCGI ----------------

Avantages : La norme FastCGI permet à un processus php unique de gérer plusieurs scripts avant de tuer le processus php. De cette façon, vous gagnez en performances car vous n'avez pas besoin de lancer un nouveau processus php pour chaque script. Vous pouvez également utiliser des accélérateurs PHP dans cette configuration (voir la section contre pour les commentaires). De plus, FCGI presque comme suphp permet également aux processus php d'être exécutés au nom de certains utilisateurs. mod_fcgid semble avoir le support fcgi le plus complet et la flexibilité pour apache.

Inconvénients : L'utilisation de l'accélérateur php en mode fastcgi entraînera une consommation de mémoire élevée car chaque processus PHP aura son propre cache de bytecode (sauf s'il existe un accélérateur qui peut utiliser la mémoire partagée pour le cache de bytecode. Existe-t-il un tel?). FastCGI est également un peu complexe à configurer. Vous devez créer divers fichiers de configuration et apporter des modifications à la configuration.

Il semble que fastcgi soit la configuration PHP la plus stable, sécurisée, rapide et flexible, cependant, un peu difficile à configurer. Mais, peut-être, j'ai raté quelque chose?

Les commentaires sont les bienvenus!

L'exécution de PHP via FastCGI vous donnera certainement le plus de flexibilité. Non seulement vous pouvez utiliser en toute sécurité un Apache mpm-worker, mais vous pouvez même utiliser un autre serveur Web (par exemple nginx).

Mais même en restant avec Apache, "PHP via FastCGI" n'est pour le moment pas une option, mais au moins deux: mod_fastcgi, mod_fcgid. En plus de cela, vous pouvez utiliser des processus FastCGI dynamiques, statiques ou externes; avec ou sans suexec. Et puis il y a le gestionnaire de processus FastCGI interne de PHP, qui est maintenant remplacé par le très joli PHP-FPM en PHP 5.3. Toutes ces options ont des avantages et des inconvénients différents et peuvent entraîner des problèmes différents.

Étant donné le choix, je choisirais mod_fastcgi avec PHP-FPM pour le moment, principalement parce qu'il permet des configurations extrêmement polyvalentes et stables.

Je ne réponds pas vraiment à votre question, mais je ne comprends pas que FastCGI soit difficile à configurer. Il est différent des autres méthodes qu'il doit remplacer (mod_php, mod_python, ...), il peut donc nécessiter une réécriture d'une partie du code. Cela peut être la partie difficile, mais pour la configuration d'Apache, au moins, je trouve que c'est un jeu d'enfant. Par exemple, je testais une application WSGI en python et je voulais voir comment elle fonctionnait avec tous les protocoles pris en charge par WSGI. Voici le fichier hôte virtuel avec les configurations pour tous les protocoles (avec mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

Cela ne me semble pas complexe. Bien sûr, FastCGI prend en charge de nombreuses options et il peut être modifié à mort, mais c'est une autre question.

Pour exécuter, c'est en tant qu'utilisateur différent, utilisez suexec et FastCGIWrapper, ensuite, cela devient:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

Et voyez ce lien pour un php.ini personnalisé, mais vous devriez pouvoir le spécifier avec l' -initial-envoption, c'est-à-dire

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/

Un bon candidat est: The Apache 2 ITK MPM

apache2-mpm-itk (juste mpm-itk pour faire court) est un MPM (Multi-Processing Module) pour le serveur web Apache. mpm-itk vous permet d'exécuter chacun de vos vhost sous un uid et un gid séparés - en bref, les scripts et les fichiers de configuration pour un vhost ne doivent plus être lisibles pour tous les autres vhosts.

A très bien travaillé pour l'un de nos clients avec des centaines de VirtualHosts avec pas mal de visiteurs.

Vous obtenez tous les avantages de l'exécution de PHP en tant que module et triez certains des inconvénients.

Pour moi, la question est de savoir à quoi sert le serveur Web. Sert-il plusieurs hôtes virtuels? Si tel est le cas, vous devez sacrifier les performances pour une sécurité isolée. Oui, les performances en souffrent, mais avec le matériel d'aujourd'hui, il devrait encore prendre un peu de trafic pour entraîner des problèmes de performances majeurs.

Si les performances sont si importantes, exécutez le seul site sur un serveur VPS ou dédié et configurez les performances.