# Sentry Profiling en continu : le budget CPU sur 90 extensions actives

> 90 extensions actives, un profiling continu activé pour tout surveiller, et une facture CPU qui grimpe plus vite que prévu. Où activer le profiling de Sentry sélectivement, et où s'en abstenir.

- Auteur : Clément Hadrot
- Publié le : 2026-09-02
- Mis à jour le : 2026-09-02
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/sentry-profiling-continu-budget-cpu-90-extensions/

## L’essentiel

- Le profiling continu ajoute un coût CPU mesurable, pas négligeable à grande échelle
- Sur 90 extensions, trois concentraient l'essentiel du surcoût observé
- Un profiling sélectif a conservé la visibilité utile sans la facture CPU complète

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.

> L'essentiel à retenir : Le profiling continu ajoute un coût CPU mesurable, pas négligeable à grande échelle ; Sur 90 extensions, trois concentraient l'essentiel du surcoût observé ; Un profiling sélectif a conservé la visibilité utile sans la facture CPU complè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.