5 Façons d’augmenter les Performances PHP – Tideways

5 Façons d’augmenter les performances PHP

BONUS: Nous avons discuté de ce sujet avec un expert de la communauté PHP dans notre podcast:

Hors de la boîte proverbiale, PHP offre des performances décentes. Cependant, il y a plusieurs choses que nous, en tant que développeurs PHP et administrateurs systèmes, pouvons faire pour augmenter encore ses performances; parfois sans effort ou presque.

Dans cet article, je vais parcourir cinq de ces façons. Au moment où vous avez fini de lire, vous devriez voir au moins une augmentation notable des performances de votre application PHP. Commençons.

Utiliser PHP 7

L’une des meilleures façons d’améliorer les performances de PHP est d’exécuter la dernière version (PHP 7). Il offre une amélioration significative de la vitesse par rapport à toute version précédente. Maintenant, les résultats varieront toujours, car il n’y a jamais deux applications identiques. Cependant, sur la base des rapports de différents développeurs et sociétés d’hébergement notables, les améliorations de performances sont significatives.

Voici un petit échantillon:

• Les benchmarks officiels de PHP signalent que PHP 7 peut exécuter deux fois plus de requêtes par seconde par rapport à PHP 5.6.
• Les benchmarks de performance PHP de Kinsta montrent que WordPress 5.0 peut exécuter 3 fois plus de transactions que PHP 5.6; et
• Pantheon a rapporté que PHP 7 a donné une amélioration de 64% par rapport à la version 5.3.

Si cela ne vous suffit pas, vérifiez vos repères et voyez ce qu’ils disent.

De plus, PHP 7.0.0 est sorti le 3 décembre 2015 et la dernière version stable, 7.3.6, est sortie le 30 mai de cette année.

De plus, la version finale de PHP 5, 5.6, est entrée en fin de vie il y a 7 mois, le 31 décembre 2018. Donc, si vous ne l’avez pas déjà fait, il est temps que vous fassiez la transition vers PHP 7. Effectuez la mise à niveau et, comme l’a dit Rasmus à phpCE 2018, passez au vert en réduisant vos coûts d’hébergement.

Désinstaller Xdebug

La prochaine chose à vérifier est que Xdebug n’est pas installé sur vos serveurs de production. Bien sûr, Xdebug est l’un des profileurs et débogueurs les plus sophistiqués et les plus complets pour PHP, mais il ne devrait jamais être activé (même installé) sur un serveur de production, au moins jusqu’à la sortie de Xdebug 3 et vous devriez nous rejoindre pour aider Derick à travailler dessus.

Bien que les benchmarks de performance varient (ils le font toujours), un rapport sur le débordement de pile a montré une augmentation des performances de 50% en supprimant complètement Xdebug. De plus, il est important de noter que même si Xdebug était installé sur le serveur, il n’était même pas activé!

Xdebug performance benchmark

Pour vérifier s’il est installé, exécutez php -m | grep -i xdebug ou vérifiez le panneau d’administration de votre hébergeur. Et si vous souhaitez en savoir plus sur le fonctionnement de Xdebug, consultez la documentation Xdebug.

Utiliser Composer Optimize Autoloader

Bien que nous soyons tous probablement très familiers avec l’utilisation de Composer pour gérer la gestion des paquets pour nous, si nous n’envisageons pas d’optimiser la configuration qu’il génère, nos applications ne fonctionneront pas aussi bien que possible.

Voici une citation de la documentation du compositeur qui explique pourquoi:

en raison de la façon dont les règles de chargement automatique PSR-4 et PSR-0 sont configurées, le compositeur doit vérifier le système de fichiers avant de résoudre un nom de classe de manière concluante. Cela ralentit un peu les choses, mais c’est pratique dans les environnements de développement car lorsque vous ajoutez une nouvelle classe, elle peut immédiatement être découverte / utilisée sans avoir à reconstruire la configuration du chargeur automatique.

Pour améliorer les performances, Composer propose trois niveaux d’optimisation ::

• Génération de cartes de classes
• Cartes de classes faisant autorité
• Cache APCu

1: Génération de Class map

Cette stratégie convertit les règles PSR-4/PSR-0 en règles classmap. Cette stratégie est plus rapide car la classmap peut renvoyer instantanément le chemin complet vers les fichiers connus et évite une opération de statistiques du système de fichiers.

Pour activer ce niveau d’optimisation, exécutez la commande suivante:

composer dump-autoload --optimize 

2/ A: Cartes de classes faisant autorité

En plus d’activer automatiquement le niveau 1, lors de l’utilisation de ce niveau, si une classe n’est pas trouvée dans le classmap généré, le chargeur automatique ne tentera pas de regarder le système de fichiers selon les règles PSR-4. Pour activer ce niveau d’optimisation, exécutez la commande suivante:

composer dump-autoload --classmap-authoritative 

2/ B: Cache APCu

Ce niveau ajoute un cache APCu comme solution de secours pour la carte de classe. Cependant, il ne génère pas le classmap. Étant donné que, le niveau un devrait être activé manuellement. Pour activer ce niveau d’optimisation, exécutez la commande suivante:

composer dump-autoload --apcu 

Il existe des compromis

Bien que chacun de ces niveaux puisse améliorer les performances de l’application, ils ont chacun des compromis qui doivent être compris avant d’être utilisés. Assurez-vous de consulter la documentation du compositeur avant de les utiliser.

Utilisez un OPcache

Puisque PHP est un langage interprété et non compilé, le runtime PHP doit convertir le code source en code d’octets exécutable avant de pouvoir être exécuté. Et comme PHP est une architecture sans partage, ce processus doit se produire à chaque demande.

Cependant, avec un cache d’Opcodes (OPcache), cette étape ne doit se produire qu’une fois pour chaque fichier, car les Opcodes générés peuvent être mis en cache dans la mémoire partagée et y être référencés à la place.

Donc, comme vous pouvez l’imaginer, un OPcache est l’un des moyens les moins intensifs d’améliorer les performances d’une application PHP, car aucun code n’a besoin de changer. Certains rapports montrent une amélioration de la vitesse allant jusqu’à 70%.

Il y a eu plusieurs caches d’opcodes pour PHP au fil des ans. OPCache (anciennement Cache Zend) est fourni avec PHP depuis la version 5.5 – et est activé par défaut dans PHP 7.

Pour en savoir plus, consultez la documentation OPcache. Pour en savoir plus sur le réglage des performances OPcache, consultez l’excellent article de Hayden James ainsi que le post de Tideway sur le réglage.

Utilisez le préchargement PHP 7

Si vous n’avez pas encore entendu parler de la nouvelle fonctionnalité de préchargement de PHP 7.4, c’est très cool! En un mot, la fonctionnalité prend la fonctionnalité Opcache plus loin que jamais auparavant.

Pour récapituler rapidement, la première fois qu’un fichier source PHP est rencontré, il doit être analysé, puis compilé en bytecode dépendant de la machine, avant que le moteur Zend puisse l’exécuter. Les Opcaches réduisent considérablement la surcharge de ce processus, car après la première analyse et compilation du code source, les bytecodes sont ensuite stockés dans un cache d’Opcodes en mémoire partagée.

La prochaine fois qu’une requête pour ce fichier est rencontrée, PHP vérifie si le cache des opcodes contient des bytecodes pour le fichier. Si c’est le cas, ils sont retournés et utilisés. Si ce n’est pas le cas (ou si le fichier source a changé depuis la compilation des bytecodes), le fichier source est analysé, compilé et mis en cache. Cela donne un coup de pouce notable aux performances de PHP.

Maintenant, regardons comment fonctionne le préchargement. Pour citer la RFC d’implémentation:

Au démarrage du serveur – avant l’exécution de tout code d’application – nous pouvons charger un certain ensemble de fichiers PHP en mémoire – et rendre leur contenu “disponible en permanence” pour toutes les requêtes ultérieures qui seront servies par ce serveur. Toutes les fonctions et classes définies dans ces fichiers seront disponibles pour les requêtes prêtes à l’emploi, exactement comme les entités internes. Le préchargement garantit que:

• Toutes les fonctions et la plupart des classes définies dans ces fichiers seront chargées en permanence dans les tables de fonctions et de classes de PHP et deviendront disponibles en permanence dans le contexte de toute demande future.
• PHP résout les dépendances de classe et les liens avec le parent, les interfaces et les traits (ce qui n’arrive pas avec la mise en cache des opcodes).
• PHP supprime les includes inutiles et effectue d’autres optimisations.

En ayant le code d’une application entière, y compris son framework (tel que Zend Expressive, Symfony et Laravel) préchargé en mémoire, code qui n’a changé qu’au redémarrage du serveur, la plupart des applications fonctionneront nettement mieux.

Cela dit, le préchargement présente quelques inconvénients potentiels que vous devez connaître:

• Un redémarrage du serveur est nécessaire lorsque les fichiers source changent.
• Le préchargement ne fonctionnera pas dans les environnements d’hébergement partagé.
• Le préchargement ne fonctionnera pas lorsqu’il existe plusieurs versions de la même application.

Le préchargement n’est pas magique. Votre code et vos processus de déploiement devront être refactorisés pour en tirer parti. Par exemple, quelqu’un devra développer un script de chargeur personnalisé pour déterminer les fichiers à charger au démarrage du serveur, et ce script devra être exécuté au démarrage du serveur. Quoi qu’il en soit, c’est une amélioration significative dans laquelle il vaut la peine d’investir!

Utilisez un Profileur

Maintenant pour une option qui prendra un peu plus de travail que l’une des cinq précédentes. Souvent, nous sautons et essayons de deviner où se trouvent les goulots d’étranglement de performance dans nos applications, en utilisant l’intuition et des suppositions éclairées.

Bien que cela puisse fonctionner, ce ne sont pas les approches les plus efficaces. Au lieu de cela, nous pouvons utiliser des profileurs de code pour analyser notre code et montrer où se trouvent les goulots d’étranglement. Plus précisément, ils aident à répondre à des questions telles que les suivantes:

• Combien de fois chaque méthode a-t-elle été appelée ?
• Quel était le temps d’exécution maximum de chaque méthode ?
• Quel était le temps d’exécution moyen de chaque méthode ?
• Combien de fois un fichier a-t-il été inclus ?
• Quel chemin une requête a-t-elle emprunté via une application (du premier au dernier fichier de code) ?

En fouillant dans les résultats d’un profileur, vous pouvez souvent être agréablement surpris, bien que plus probablement choqué, de constater que votre application exécute des chemins de code et des classes auxquels vous ne vous attendiez pas.

Sur la base des informations contenues dans le rapport du profileur, vous et votre équipe pouvez alors commencer à mieux comprendre ce que fait votre application et effectuer des refactorisations informées pour la modifier, au besoin.

Si vous débutez avec le profilage, plusieurs options sont disponibles pour PHP. Les plus couramment utilisés sont:

• Le profileur de Xdebug
• L’extension XHProf de Tideway (& XHGui)
• Profileur spx
• forp

En conclusion

Et ce sont cinq façons d’améliorer la qualité de vos applications PHP notamment. Chacun d’eux seul vous apportera une amélioration notable des performances. Cependant, lorsqu’il est utilisé ensemble, vous devez vous attendre à voir une performance significative, sans parler de la qualité, de l’amélioration.