Ce que Performance Agent a découvert sur un site Drupal pour 90 centimes

On avait un client qui s'apprêtait à tester Performance Agent pour la première fois et qui voulait voir comment ça marchait sur un projet qu'il contrôlait avant de le présenter à d'autres. Il a donc mis en place un projet Drupal jetable, écrit du code de module personnalisé et y a délibérément glissé une requête N+1. Le genre de chose facile à écrire et facile à rater lors d'une révision.

Puis il a lancé l’agent.

Le bug qu’il avait introduit

L’agent a détecté la requête N+1. C’était le test décisif, et il l’a réussi. Le rapport indiquait le code personnalisé, expliquait le coût en termes simples et proposait un correctif qu’ils décrivaient comme prêt à être appliqué.

Bien, mais c’était le bug qu’ils avaient mis là exprès pour qu’il soit trouvé. Ils n’avaient rien dit à l’agent à ce sujet, ils l’avaient juste dirigé vers l’application.

Le bug qu’ils n’avaient pas

C’est la deuxième découverte qui les a poussés à rédiger leur rapport. Le projet disposait de Redis en tant que service, et d’après ce que tout le monde croyait, Drupal l’utilisait. Ce n’était pas le cas. Le backend de cache n’avait en réalité jamais été connecté à Redis, donc chaque lecture du cache passait discrètement par la base de données. L’agent a estimé que ça représentait environ la moitié du temps de requête sur les routes qu’il avait examinées.

Personne n’a planté ça. C’est une fin de parcours courante pour un projet Drupal : tu ajoutes un service, la configuration qui devrait le pointer n’est jamais mise en place, et rien ne fait assez de bruit pour que quelqu’un s’en aperçoive. Un profil te montrerait un temps d’accès à la base de données important. Mais il ne te dirait pas que la raison, c’était un cache qui croyait être Redis. Pour passer de l’un à l’autre, il faut comparer côte à côte le profil, la topologie des services et la configuration de l’application, et c’est justement ce que fait l’agent, ce qu’un profileur seul ne peut pas faire.

Le reste

Les autres résultats concernaient des réglages : paramètres d’opcache et optimisation de l’autochargeur, tous deux corrigés par des correctifs. Rien d’extraordinaire, mais exactement le genre de choses qui finissent sur une liste et y restent.

Les chiffres

L’exécution complète a pris quelques minutes. Le coût du modèle sur sa propre clé API s’élevait à 0,90 $. Le coût de calcul du conteneur de tâches pour ces quelques minutes d’exécution est négligeable par rapport à ça. Ils avaient laissé le plafond budgétaire par défaut de 5 $ en place et ne s’en sont même pas approchés.

Pourquoi ce profil est important

La plupart des assistants IA pour les problèmes de production analysent les logs, les métriques et les traces. Ceux-ci t’indiquent qu’un point de terminaison a ralenti à 14 h 02. Ils ne te disent pas quelle fonction est en cause ni ce qu’il faut modifier, car ces informations se trouvent dans le profil et dans le code.

Le Performance Agent part du profil. Il lit les profils Blackfire et les données de profilage en continu provenant de l’environnement déployé, utilise le trafic pour déterminer quels points de terminaison comptent vraiment pour les utilisateurs, puis analyse le code source pour trouver la solution. La découverte concernant Redis illustre bien pourquoi cette combinaison est essentielle. Aucune de ces données, prise isolément, n’aurait permis d’aboutir à ce résultat.

Essaie-le d’abord sur quelque chose que tu contrôles

Choisis un projet où tu sais qu’il y a au moins un problème. Crée-en un si nécessaire. Lance l’agent, vérifie s’il détecte le problème que tu connais déjà, puis prête attention à tout ce qu’il met en évidence, car c’est cette deuxième partie qui te dira si ça vaut le coup de l’appliquer à l’environnement de production.

La configuration se résume à quelques lignes de .upsun/config.yaml, une clé API d’Anthropic ou d’OpenAI stockée en tant que variable sensible, et un redéploiement. La doc explique tout ça. Ça tourne sur Upsun Cloud et ça génère un rapport sans rien modifier.