Optimisations de l'application pour PHP7

Certaines personnes pensent qu'il n'est pas nécessaire d'optimiser les programmes informatiques et qu'il suffit d'acheter des machines plus puissantes en cas de mauvaises performances. Ce n'est pas la philosophie du projet Jorani pour plusieurs raisons :

• Jorani a été conçu pour l'ONG Passerelles numériques. Cette dernière opère dans des pays d'Asie du sud-est où l'accès Internet est parfois très lent. Si le temps de traitement informatique est très court sur le serveur, cela accélèrera le temps de réponse global.
• Un code performant permet de réduire l'empreinte environnementale d'une application. Les CPU actuels ont une consommation électrique dynamique variant en fonction de leur charge. En outre, une application peu gourmande en ressources telle que Jorani peut facilement partager un environnement mutualisé.
• Beaucoup d'applications sont hébergées sur des machines virtuelles ou des serveurs mutualisés afin de réduire les coûts. Nous avons gardé en tête ces cas d'utilisation étant donné que nous visons les ONG et associations.

La version 0.4.2 a donc été optimisée afin de remplir ces objectifs. Nous avons également profité pour nous assurer qu'elle serait 100% compatible avec PHP7. Cette dernière version de PHP — couplée à Opcache — améliore grandement les temps de réponse de l'application.

Nous voulons remercier SensioLabs qui nous permet d'utiliser gratuitement la version complète de l'outil de profiling PHP blackfire dans le cadre du projet Jorani. Comme nous allons le voir plus bas, cela nous a permis de découvrir plusieurs axes d'optimisation.

Méthodologie du test de charge

Nous avons créé un script JMeter que vous pouvez trouver sur le dépôt du projet. Afin d'exclure une partie des temps réseau, les composants statiques (JS, CSS, images, etc.) ne sont pas téléchargés, car nous nous intéressons seulement au temps de calcul des différents moteurs PHP. De même, le test d'effectuera pas d'écriture en base de données.

La base a été chargée avec 2000 utilisateurs et 7000 demandes de congé (voir le fichier Excel dans le répertoire donné en lien).

Nous avons utilisé un VPS hébergé par OVH avec un VCPU et 1 Go de RAM. Nous avons limité le test à 30 utilisateurs simultanés et des pauses de moins de 10 secondes entre les étapes. À l'exception d'OpCache, Les machines PHP sont lancées avec leur configuration par défaut en tant que serveur FastCGI.

Nous avons testé la dernière version de développement de PHP7 (le 20/09/2015) et avons paramétré Opcache que nous vous encourageons vivement à activer.

Synthèse des résultats

Le tableau ci-dessous — qui liste les temps moyens de réponse en millisecondes — montre des excellents temps de réponse que nous essayons de réduire en dessous de 100ms côté serveur (pour rappel, ces temps sont composés d'un temps de traitement côté serveur, ainsi que du téléchargement du résultat de l'exécution du code PHP).

Matrice des composants techniques

En plus du framework MVC CodeIGniter 2.2.X, Jorani utilise les bibliothèques tierces listées dans le tabeau suivant.

Comment avons-nous dopé Jorani?

Nous avons utilisé blackfire afin de faire une analyse dynamique du code de Jorani.

Blackfire est rapide à installer côté serveur et un add-in existe pour les principaux navigateurs afin de capturer rapidement une session de profiling dans les cas les plus simples. Si cela se complique, on peut instrumentaliser le code ou encore activer le profiler XDebug, pour ensuite téléverser les traces de profiling sur le serveur blackfire.

Débusquer les erreurs les plus grossières

Lorsque l'on ouvre une trace de profiling sur le site blackfire, on a accès aux chiffres-clés tel que le temps total côté serveur, le temps des entées/sorties, le temps de calcul par le CPU ou des indicateurs concernant la base de données. Avec la capture d'écran ci-dessous, on comprend que certaines requêtes similaires sont exécutées plusieurs fois. Cela peut venir d'un souhait de factorisation du code. C'est une bonne pratique, mais parfois, dupliquer quelques lignes de code peut booster les performances d'une application.

• 

  Indicateurs-clés d'une session de profiling avec blackfire

Isoler le goulet d'étranglement

Un autre grand classique des outils de profiling consiste à fournir quelques statistiques sur les fonctions (temps d'exécution inclusif et exclusif, nombre d'appels, etc.). Ici, nous avons pu identifier un problème lié au framework CodeIgniter lorsqu'il accède au cookie de session sécurisé. C'était un problème, car cette partie du code pouvait être plus lente qu'une interrogation SQL. La modification d'une des bibliothèques du framework nous a permis de réduire très fortement les temps de réponse de toutes les pages de l'application (car cette fonction était appelée systématiquement).

• 

  Fonctions les plus lentes identifiées par blackfire

Nous espèrons que vous apprécierez ces optimisations ainsi que toutes celles que nous n'avons pu décrire dans cet article.