Installations de PHP et comportement du cache d’Opcode

Dans mon billet précédent sur l’installation de PHP-FPM, vous vous souvenez peut-être du paragraphe intitulé « Côté cache d’opcode » où j’évoquais le fonctionnement différent du système de cache d’Opcode en fonction du type d’installation de PHP.

Je profite de petits tests effectués avec cinq installations de PHP différentes (mod_PHP, FastCGI, FCGI, PHP-FPM avec Apache2 et enfin PHP-FPM avec Nginx) pour compléter mes propos. Ces tests, non exhaustifs montrent aussi l’influence du cache d’Opcode sur les performances du serveur Web.

1. Les tests

La procédure

Les tests ont été effectués sur une même machine virtuelle sous Debian 5 (+ Dotdeb pour PHP 5.3.3). La VM est dotée de 2Go de RAM, de 2 coeurs de processeur Intel Xeon E5430 @2.66 GHz et stockée sur des disques dur SAS 15K tr/min en RAID 10. Pour chaque installation de PHP, j’ai effectué les tests avec le cache d’opcode APC désactivé, puis activé (avec une configuration par défaut) et enfin activé avec la directive « stat » à 0.

Le test consiste à requêter 1000 fois (avec 10 connexions concurrentes) les « ressources » suivantes :

  • une page statique (contenant le html d’une page phpinfo)
  • une page PHP, un simple phpinfo()
  • un « hello Sf2″ sous Symfony2 (Sandbox)

et sur une des installations seulement :

  • la page d’acceil d’un WordPress 3 (installation de base)

Chaque test est répété 3 fois de suite.

PHP-CGI avec Apache2, mpm-worker, suEXEC, FCGID

Apache2 est installé avec le MPM Worker, avec suEXEC pour gérer les utilisateurs Web par hôte virtuel. Notre configuration de FCGID limite le nombre de processus parents à 10 et 0 processus enfant.

=> Avec FCGID, le cache d’opcode est dans ce cas multiplié par le nombre de processus parents quelque soit l’utilisateur web propriétaire du processus.

APC \ Page (req/s)statiquephpinfo()hello Symfony2WP 3
OFF418971370
ON (stat 1)4321710116
ON (stat 0)4204713186

PHP-CGI avec Apache2, mpm-worker, suEXEC, FastCGI

Apache2 est installé avec le MPM Worker, avec suEXEC pour gérer les utilisateurs Web par hôte virtuel. Notre configuration de FastCGI limite le nombre de processus parents à 1, PHP gère les processus enfant dans une limite de 10.

=> Avec FastCGI, en limitant le processus parent à 1, le cache d’opcode est unique par utilisateur web et partagé entre processus enfants.

APC \ Page (req/s)statiquephpinfo()hello Symfony2WP 3
OFF389562167
ON (stat 1)3838584111
ON (stat 0)4055595173

PHP-FPM avec Apache2, FastCGI

Apache2 est installé avec le MPM Worker, PHP-FPM gère totalement les processus PHP.

=> Avec PHP-FPM, le cache d’opcode est unique et partagé entre tous les utilisateurs « web » gérés par PHP-FPM.

APC \ Page (req/s)statiquephpinfo()hello Symfony2WP 3
OFF3985665698
ON (stat 1)398166511215
ON (stat 0)396367818515

PHP en module d’Apache, avec Apache2, mpm-prefork

Apache2 est installé avec le MPM Prefork et PHP en module.

=> Avec PHP en module d’Apache, le cache d’opcode est unique, il n’y a de toute façon qu’un seul utilisateur, celui du serveur Web.

APC \ Page (req/s)statiquephpinfo()hello Symfony2WP 3
OFF4319787121
ON (stat 1)3925730425
ON (stat 0)4264760472

PHP-FPM, Nginx

Par curiosité, parce que j’entends très souvent parlé de Nginx pour ces performances, j’ai voulu comparer non pas le comportement de l’Opcode puisque celui-ci est identique à une installation PHP-FPM sous Apache2, mais plutôt voir comment Nginx s’en sortait par rapport à Apache2.

APC \ Page (req/s)statiquephpinfo()hello Symfony2WP 3
OFF817475870
ON (stat 1)9303739115
ON (stat 0)7687737191

2. Conclusion

Les différents tests m’ont permis de montrer l’importance du cache d’Opcode sur des solutions faisant appel à de nombreux fichiers comme les frameworks (ici Symfony2). Dans ce cas, on notera aussi une influence sur le paramétrage du cache d’opcode. En effet, en désactivant la surveillance de mise à jour des fichiers sources (APC stat à 0), les performances grimpent encore. Passer stat à 0 peut aussi conduire à de drôles de comportement si vous le faite sans en comprendre réellement la portée. Dans le cas de la page d’accueil de WordPress 3, cette fonctionnalité n’a plus aucun effet, le système semble complètement étranglé par l’accès aux données. En dehors de l’influence du cache d’opcode sur les performances, on notera aussi la manière dont celui-ci est partagé entre utilisateur « web ».

Malgré une duplication certaine du cache d’opcode, l’installation FCGID offre des performances légèrement meilleures que celles de l’installation FastCGI. Cependant, cette situation de multiplication du cache peut entrainer des fonctionnements assez aléatoires, la consommation de RAM peut aussi s’envoler. L’installation en FCGID est à mon avis déconseillée, du moins pour utiliser le cache d’Opcode. En léger retrait, l’installation avec FastCGI est efficace si l’on veut mutualiser plusieurs comptes sur un serveur de manière sécurisée. PHP-FPM est une très bonne solution si l’on garde bien en tête que le cache d’Opcode est partagé entre les utilisateurs « web ». C’est PHP en module d’Apache qui offre les meilleurs performances, mais par rapport aux autres installations, elle n’offre pas le même niveau de sécurité (cela se paye aussi en terme de performance), les processus PHP sont contenus dans les processus Apache qui deviennent lourds.

Pour finir et sans rapport réel avec le comportement de l’Opcode, le test de PHP-FPM avec Nginx montre que s’il n’y a pas photo sur le statique, côté PHP, c’est équivalent à Apache2. Bon, ce n’est qu’un simple constat, sur la base de mes tests. Je ne connais pas Nginx, et je m’attendais à quelque chose de différent pour PHP… Allez, encore un sujet à explorer.

N’hésiter pas à me faire part de vos expériences, de vos remarques.

Les billets suivant peuvent vous intéresser :

2 réponse à Installations de PHP et comportement du cache d’Opcode

  1. le août 17, 2011 à 7:12 , Kissifrot dit:

    En parlant de cache d’opcode, sais-tu si le suivi de l’upload d’APC (apc.rfc1867 et ce qui tourne autour) fonctionne avec PHP-FPM ?

    • le août 17, 2011 à 7:16 , Fabien dit:

      Je n’ai pas testé l’upload via APC.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>