L’article de JoliCode explique comment un problème de performance dans une application Symfony a été diagnostiqué et résolu. Le composant Cache de Symfony, via son mécanisme de protection anti-stampede (peu documenté), a été identifié comme responsable de ralentissements inattendus, notamment dans une médiathèque d’administration et des endpoints d’API. Les symptômes incluaient des temps de réponse aléatoires et une première visite lente, sans lien avec le stockage ou les requêtes SQL.
Après avoir écarté plusieurs pistes (stockage, optimisations SQL), le diagnostic a révélé que le temps était perdu dans LockRegistry::compute, bloqué par des verrous (flock) liés au cache. Le problème, absent en préproduction, illustre les pièges des mécanismes de cache mal compris, même dans des environnements identiques.
La solution a consisté à ajuster la configuration du cache pour limiter l’impact de cette protection, évitant ainsi les attentes inutiles. L’article souligne l’importance du profilage en production pour identifier des causes contre-intuitives, plutôt que de se fier à des hypothèses.
