Surveillez la performance de votre application PHP

Vous avez écrit des tests de performance, mais ils sont encore perfectibles.

Tout d'abord, nous l'avons vu ensemble, nos tests comparent des valeurs de temps et de mémoire. Ces valeurs - pour des raisons matérielles - peuvent évoluer, ces tests peuvent parfois échouer. Il est donc difficile d'évaluer la régression entre deux tests... mais ici encore Blackfire nous propose plusieurs solutions ;).

Confirmez la non-régression

Pour contrôler l'évolution de la performance, vous pouvez donc écrire des tests sur les profils de comparaison. C'est ce qui va garantir la non-régression de la performance entre deux modifications.

Plutôt que de se reposer sur des comparaisons de valeurs, pourquoi ne pas se reposer sur une évolution de la performance ?

# La consommation de mémoire ne doit pas trop augmenter
percent(main.memory) < 5%

Une autre fonction est également très utile, la fonction diff, pour mesurer la différence de valeur sur le profil de comparaison.

# La différence de temps ne doit pas augmenter de plus de 100ms
diff(main.wall_time) < 0.1s

Complétons le fichier .blackfire.yml précédent :

# .blackfire.yml

tests:
    "Toutes les pages sont rapides":
        path: "/.*"
        assertions:
            - main.wall_time < 60ms
            - main.memory < 2Mb
    "Tests spécifiques à Symfony":
        path: "/.*"
        assertions:
            - metrics.symfony.kernel.debug.count == 0 # En mode production
            - metrics.symfony.yaml.reads.count == 0 # Mise en cache du YAML
    "Tests spécifiques à Twig":
        path: "/.*"
        assertions:
            - metrics.twig.compile.count == 0 # Pas de compilation en production
            - metrics.twig.attributes.get.count < 30 # Pas trop de logique dans les templates
    "Tests de non régression":
        path: "/.*"
        assertions:
            - percent(main.memory) < 5% # Contrôle de la consommation de mémoire
            - diff(main.wall_time) < 0.1s # Contrôle du temps de chargement du script

Écrivez des tests efficacement

Écrire de bons tests est une tâche difficile. Les tests les plus simples concernent des comparaisons sur le temps de chargement d'un script ou sur la consommation de mémoire.

Pourtant, ces tests sont très vulnérables et devraient être évités.

Le temps et la mémoire ne sont pas des métriques stables. Nous l'avons vu, ces métriques dépendent du matériel et ces valeurs peuvent évoluer d'un rapport à l'autre.

Oubliez les comparaisons de temps

Le temps ou la consommation de mémoire vive ne sont que la conséquence des actions réalisées par le code. Comprendre ce que font ces fonctions et comment les améliorer est le rôle de Blackfire.

Si le temps ou la mémoire vive permettent d'identifier les parties les plus lentes de vos applications, vous devez écrire des tests sur les causes réelles du problème.

Par exemple, si une majorité des ressources de votre application est consommée par les requêtes SQL :

# mauvaise idée...
main.wall_time < 50ms

# meilleure idée!
metrics.sql.queries.count < 10

Sur beaucoup de sites à fort trafic,  un prérequis est de ne pas avoir de requêtes SQL du tout sur la première page :

metrics.sql.queries.count == 0

Une autre bonne pratique est de ne pas effectuer de tâches "lourdes" de façon synchrone, comme l'envoi de mails par exemple :

metrics.emails.sent.count == 0

Enfin, il faut s'assurer qu'un serveur de production repose sur un cache déjà construit, notamment pour Twig et Doctrine, dans le cadre d'une application Symfony :

# Bonnes pratiques pour une application Symfony

# Pas de compilation Twig
metrics.twig.compile.count == 0

# Pas de contrôle de méta-données Symfony
metrics.symfony.config_check.count == 0

# Le cache Doctrine est utilisé
metrics.doctrine.annotations.parsed.count + metrics.doctrine.annotations.read.count + metrics.doctrine.entities.metadata.count + metrics.doctrine.proxies.generated.count == 0

# Le Yaml n'est pas utilisé en production
metrics.symfony.yaml.reads.count == 0

En résumé

Blackfire a une approche centrée sur les fonctions et les métriques de la performance. Écrivez de bons tests et ils vous permettront de trouver rapidement les problèmes avant même d'avoir analysé le graphe de comparaison.

Quelques bonnes pratiques à retenir :

• ne pas dépendre des métriques, mais de l'évolution de l'application ;

• ne pas se reposer sur le temps ou la mémoire, mais sur les causes réelles qui entraînent l'évolution de la performance ;

• les bonnes pratiques pour les applications en production sont facilement testables avec Blackfire.

Malgré les très nombreuses métriques fournies par Blackfire, vous pourriez vous sentir limité, ou dans l'incapacité de vérifier un comportement spécifique de votre application.

C'est pourquoi il est possible de créer ses propres métriques dans Blackfire. C'est ce vous découvrirez dans le prochain et dernier chapitre de ce cours :soleil: !