9,4 % de charge CPU en plus, mesurée sur un mois complet, uniquement pour la fonctionnalité de profiling continu de Sentry activée sur l’ensemble d’un site d’agence chargé en extensions hétérogènes. Le site en question, une plateforme interne cumulant 90 extensions actives pour couvrir les besoins de plusieurs équipes (formulaires, paiement, recherche, SEO, sécurité, intégrations tierces), avait activé le profiling continu par prudence, pour repérer d’éventuelles régressions de performance sans attendre un signalement utilisateur.
Le profiling continu de Sentry échantillonne l’exécution du code à intervalles réguliers, bien au-delà du simple suivi des transactions HTTP classique, pour reconstituer une vue détaillée du temps CPU consommé fonction par fonction. Cette granularité a un coût, et sur un site à 90 extensions, ce coût s’est avéré loin d’être négligeable une fois mesuré précisément plutôt que supposé.
Comment mesurer le vrai coût du profiling
La méthode retenue a consisté à faire tourner deux environnements strictement identiques en parallèle pendant deux semaines, l’un avec le profiling continu activé, l’autre sans, en répliquant le même trafic grâce à un miroir de requêtes basé sur les journaux d’accès réels. Cette approche a permis d’isoler l’effet du profiling de toute variation naturelle de trafic entre les deux périodes.
L’écart de charge CPU moyen constaté, 9,4 %, correspondait globalement aux ordres de grandeur documentés par Sentry lui-même pour un taux d’échantillonnage par défaut, mais restait supérieur aux attentes de l’équipe, qui avait sous-estimé l’effet cumulé sur un site aussi chargé en extensions tierces exécutant chacune leur propre code à chaque requête.
Les trois extensions qui concentraient le surcoût
En croisant les profils collectés avec la liste des extensions actives, trois d’entre elles concentraient à elles seules près des deux tiers du surcoût CPU imputable au profiling : une extension de recherche interne qui exécutait de nombreuses fonctions courtes et fréquentes (donc plus coûteuses à échantillonner proportionnellement), une extension de sécurité qui interceptait chaque requête via plusieurs hooks successifs, et un module de paiement tiers dont le code, non minifié côté serveur, comportait une profondeur d’appel inhabituelle.
| Extension | Part du surcoût profiling | Raison probable |
|---|---|---|
| Recherche interne | 28 % | Fonctions courtes et très fréquentes |
| Sécurité (hooks multiples) | 21 % | Interception à chaque requête sur plusieurs hooks |
| Module de paiement tiers | 17 % | Profondeur d’appel élevée |
| Les 87 autres extensions cumulées | 34 % | Effet diffus, aucune ne dépassant 2 % |
La décision : profiling sélectif plutôt que global
Plutôt que de désactiver purement le profiling, ce qui aurait fait perdre toute visibilité sur d’éventuelles régressions futures, la décision a consisté à réduire le taux d’échantillonnage global à 10 % des transactions au lieu de 100 %, tout en gardant un taux plus élevé ciblé spécifiquement sur les parcours critiques (paiement, recherche), configuré via le SDK Sentry côté PHP avec un échantillonnage dynamique selon le type de transaction.
Sentry\init( [
'dsn' => SENTRY_DSN,
'profiles_sample_rate' => function ( $context ) {
if ( $context->getTransactionName() === 'paiement.validation' ) {
return 0.5;
}
return 0.1;
},
] );Résultat après ajustement
- Charge CPU supplémentaire ramenée de 9,4 % à environ 1,8 % sur l’ensemble du site.
- Visibilité conservée intégralement sur les parcours de paiement, jugés les plus critiques en cas de régression.
- Perte de granularité acceptée sur les extensions les moins sensibles, avec la possibilité de remonter temporairement l’échantillonnage en cas de doute ponctuel.
Un taux d’échantillonnage à 100 % en continu se justifie rarement en production. Le profiling est un projecteur, pas un plafonnier : il doit s’orienter vers ce qui compte, pas tout éclairer en permanence.
Ce que ce chiffre ne dit pas
Le surcoût de 9,4 % mesuré sur ce site n’est pas une constante universelle : il dépend directement du nombre et de la nature des extensions actives, du volume de trafic, et du taux d’échantillonnage initial choisi. Un site avec une dizaine d’extensions bien codées observerait probablement un chiffre bien plus faible ; l’accumulation de 90 extensions hétérogènes, typique d’un site d’agence multi-équipes, amplifie l’effet.
Bilan
Le profiling continu reste un outil précieux pour anticiper les régressions de performance, mais son coût réel mérite d’être mesuré avant d’être généralisé sur un site déjà chargé en extensions tierces. Un échantillonnage différencié, plus fin sur les parcours critiques et plus léger ailleurs, a permis de garder l’essentiel de la visibilité sans payer le prix fort du profiling exhaustif.
