Petit cas d’optimisation PHP
Cet article a été publié il y a 7 ans 5 mois 17 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.J’ai choisi de vous faire un retour d’expérience suite au récent passage en production d’un client chez nous. C’est particulièrement intéressant sur plusieurs points, notamment sur PHP qui tabassait pas mal.
Le contexte
Une VM, 3vCPU, 4Go de RAM, PHP 5.6 avec Zend Opcache d’activé, et un load de 8 presque intégralement dû à PHP-FPM. La base de données est sur un deuxième serveur, et se tourne magistralement les pouces. Dernière précision, le site est un Drupal 7, dans une configuration très classique.
strace à la rescousse
Un peu comme pour le débug du blog, j’ai eu recours à strace pour essayer de comprendre ce qui se passait. En effet, quand on regarde htop, la moitié du CPU est taggé « system ». Tiens donc. atop me confirme des entrées/sorties conséquentes. Le phénomène étant différent, j’ai procédé différemment avec strace :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
[root@client-web-01:~]# timeout 60 strace -c $(ps fauxw | egrep "fpm" | grep "client" | awk '{print "-p " $2}' | tr "\n" " ") (...) % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 93.53 5.519480 1 7620127 1152 lstat 3.11 0.183691 1 245392 getcwd 1.56 0.092117 1 108138 34 stat 0.68 0.040011 1 29069 getdents 0.30 0.017911 1 14552 openat 0.28 0.016786 1 14588 close 0.21 0.012170 4 3349 sendto 0.12 0.006992 2 4512 recvfrom 0.10 0.005789 1 4512 poll 0.05 0.002970 6 482 brk 0.04 0.002138 1 2316 237 access 0.01 0.000489 2 284 epoll_wait 0.00 0.000247 1 303 303 readlink 0.00 0.000143 3 47 19 write 0.00 0.000107 1 164 read 0.00 0.000092 1 138 getsockopt 0.00 0.000088 2 49 chdir 0.00 0.000074 4 18 18 connect 0.00 0.000054 1 37 open 0.00 0.000052 1 88 fcntl 0.00 0.000038 2 18 munmap 0.00 0.000036 2 18 mmap 0.00 0.000027 0 55 fstat 0.00 0.000025 0 69 setitimer 0.00 0.000012 1 18 accept 0.00 0.000012 1 17 13 shutdown 0.00 0.000012 0 34 times 0.00 0.000009 1 18 socket 0.00 0.000008 0 35 lseek 0.00 0.000005 0 18 rt_sigaction 0.00 0.000005 0 18 setsockopt 0.00 0.000004 0 18 rt_sigprocmask ------ ----------- ----------- --------- --------- ---------------- 100.00 5.901594 8048501 1776 total |
Mmmmh, beaucoup de lstat, donc du disque (on voit d’ailleurs d’autres appels tous dans le même domaine), on sait que ça reste l’élément le plus lent d’une machine, et le « cloud » ne fait évidemment pas de miracles de ce côté-là. Mais pour quelle raison ?
Analyse de la configuration de PHP
J’ai voulu proposer l’activation de Zend Opcache, avant de découvrir qu’il était déjà en service. Je me suis donc tourné vers la configuration PHP, un phpinfo me permettant de noter ces deux lignes :
|
1 2 |
opcache.validate_timestamps = 1 opcache.revalidate_freq = 60 |
Ok, donc ça veut dire qu’il relit les métadonnées des fichiers pour vérifier s’il y a eu des modifications et ce toutes les 60 secondes. le phpinfo n’étant pas assez détaillé pour moi je me tourne vers une page de status un peu comme celle qui existe pour APC :
Avec 660 fichiers ( j’ai pris la capture après avoir résolu le problème, il y avait plus de 900 scripts qui étaient étaient chargés), et un délai avant revalidation de 60 secondes seulement, autant dire qu’il passait son temps à lire les fichiers sur le disque, consommant massivement des ressources CPU.
La solution n’est pas venu d’Opcache
Non, en effet, je me suis tourné vers une autre recherche sur Google (parce que c’est celui qui est configuré sur mon poste au boulot, et ça convient dans ce cadre en particulier), avec les termes « php reduce lstat syscalls ». Et là, j’ai découvert un article en anglais évidemment très intéressant, qui détaille qu’il existe un « bug » si on utilise open_basedir.
Si open_basedir est activé/défini, pas de realpath_cache, qui est un cache/tampon qui enregistre le chemin des fichiers pour une durée déterminée (par la variable realpath_cache_ttl) plutôt que revalider systématiquement tous les chemins de tous les fichiers. Et quand on dit tous les chemins, c’est que pour chaque fichier, il va vérifier chaque étape dudit chemin. Par exemple, si vous stockez votre index.php dans /home/sites_web/client/www/index.php, il va faire un lstat sur /, puis sur /home, puis sur /home/sites_web/, et ainsi de suite jusqu’au fichier en lui-même. et ça pour tous les fichiers, et on a vu qu’il y en avait plus de 900 enregistrés alors.
J’ai donc désactivé l’open_basedir, et le load est retombé à 2. Boum. La solution à portée d’un « ; » pour commenter une ligne dans un fichier php.ini.
La magie du Avant/Après
La même avec le load
La raison : la sécurité
Pour rappel, open_basedir permet de restreindre l’exécution de PHP dans un dossier en particulier, une sorte de chroot version PHP en somme. Le realpath cache, lui, mémorise les chemins et les droits d’accès associés pour tous les scripts qu’il doit lire, et ce afin de ne pas recalculer les droits et chemins réels à chaque fois.
Vous comprenez le souci, si on valide un chemin, qui est dans l’open_basedir, qu’on le met en cache pendant un certain temps, il ne sera pas revérifié si ce chemin est remplacé par un lien symbolique situé en dehors du « chroot », permettant par la même occasion d’exécuter du code sans contrôle, ce qui est effectivement un problème de sécurité. Le détail technique toujours en anglais est présenté dans ce rapport de bug qui explique la situation, et les raisons du choix de désactiver le cache realpath si open_basedir est défini.
Aller plus loin dans l’optimisation opcache
Avec tout ça je me suis quand même mangé deux heures de lecture à propos du Zend Opcache et de ses bénéfices ainsi que des bonnes pratiques à adopter pour une utilisation en production. Si j’ai le courage un jour j’en ferai une traduction, mais vous pouvez vous pencher sur cet article déjà pour commencer à faire joujou avec l’Opcache. Et si vous n’en utilisez pas encore un, il est peut-être temps de s’y mettre.
Très très bon article ! Par contre en voulant tester la commande strace (avec l’ensemble des paramétres comme ci-dessus) il demande le pid, comment savoir lequel lui fournir ?
Hello, c’est le rôle ce qui se trouve dans le $() après strace -c. En particulier, le print « -p $2 » de awk (-p est le switch qui permet à strace de sélectionner le PID).
Dans l’article sur la « réparation d’article SSH » (https://blog.seboss666.info/2016/04/comment-jai-repare-larticle-sur-la-securisation-ssh/) je montre un autre exemple d’utilisation de strace, pour récupérer automatiquement le sésame qu’il lui faut.
Si c’est pour analyser le comportement d’une commande que tu souhaites lancer, tu peux utiliser strace
Merci pour ta réponse. Je commence à utiliser strace depuis peu et tu t’en doutes par besoin 😀 Il m’a déjà dépatouillé et permis d’accélérer mon application par 3 juste en m’indiquant que gettext c’est lent et qu’il vaut mieux un tableau php :p. Mais le format que tu utilises est très intéressant. Merci 🙂