Sentry Performance sur WooCommerce : le coût réel mesuré au checkout

340 millisecondes. C’est l’écart de TTFB (time to first byte) observé sur la page de paiement d’une boutique WooCommerce entre une version sans instrumentation et la même version avec Sentry Performance activé à pleine capacité. L’écart n’apparaît pas sur les pages de catalogue, à peine sur la fiche produit, mais explose précisément là où l’argent change de main : le tunnel de commande.

Sentry Performance a été introduit dans le SDK PHP courant 2019 pour compléter le traçage d’erreurs classique par des transactions et des spans qui suivent le temps passé dans chaque portion de code. Sur un site vitrine, l’overhead est négligeable. Sur un checkout WooCommerce, où une seule requête HTTP déclenche des dizaines de hooks, des calculs de taxes, des appels à la passerelle de paiement et plusieurs écritures en base, le nombre de spans générés grimpe très vite, et chaque span a un coût de sérialisation avant l’envoi au serveur Sentry.

Ce que révèle le profil d’une transaction de paiement

En activant traces_sample_rate à 1.0 sur l’environnement de test, chaque passage en caisse génère une transaction Sentry contenant, dans notre cas, entre 60 et 90 spans : validation du panier, recalcul des taxes, appel à la passerelle de paiement, création de la commande, mise à jour du stock, envoi des e-mails transactionnels. Chacun de ces spans est un objet PHP instancié, horodaté, puis sérialisé en JSON avant d’être mis en file pour l’envoi asynchrone au serveur Sentry.

Le coût ne vient pas de la latence réseau : l’envoi se fait normalement en tâche de fond via register_shutdown_function. Il vient du travail effectué pendant la requête elle-même, avant que la réponse ne soit renvoyée au navigateur : instrumentation des hooks, construction de l’arbre de spans, et dans certaines configurations, un flush synchrone qui bloque la réponse HTTP tant que la transaction n’est pas transmise.

Isoler la cause avec un test A/B contrôlé

Pour mesurer précisément l’impact, nous avons comparé quatre configurations sur le même serveur, avec le même trafic simulé via un script de commande automatisé :

• Sans SDK Sentry du tout : TTFB de référence sur le checkout.
• SDK Sentry avec erreurs uniquement (pas de traçage de performance) : surcoût négligeable, inférieur à 15 ms.
• SDK Sentry avec traces_sample_rate à 1.0 : surcoût de 340 ms en moyenne sur dix commandes consécutives.
• SDK Sentry avec traces_sample_rate à 0.1 : surcoux résiduel de 12 ms, car même les transactions non retenues nécessitent un minimum d’instrumentation pour décider de l’échantillonnage.

Échantillonner sans perdre en visibilité

La solution n’est pas de désactiver le traçage de performance sur le checkout, précisément la zone où l’on veut le plus de visibilité en cas de ralentissement. La bonne pratique consiste à échantillonner de façon dynamique selon le contexte de la requête, avec un callback passé à traces_sampler plutôt qu’un taux fixe :

\Sentry\init([
    'dsn' => SENTRY_DSN,
    'traces_sampler' => function ( $context ) {
        $path = $context->getTransactionContext()->getName();
        if ( strpos( $path, 'checkout' ) !== false ) {
            return 0.3; // échantillon plus large sur la zone critique
        }
        return 0.02; // reste du site, quasiment pas de traçage
    },
]);

Ce réglage conserve une visibilité statistiquement exploitable sur le tunnel de paiement (30 % des transactions tracées suffisent à détecter une dégradation) tout en ramenant le coût moyen constaté à environ 60 ms sur les commandes échantillonnées, et proche de zéro sur les autres.

Ce qu’il faut vérifier avant de généraliser

Trois points méritent d’être contrôlés avant de déployer ce réglage en production :

1. Le nombre de spans par transaction : au-delà de 100, envisagez de désactiver l’instrumentation automatique de certains hooks WooCommerce peu utiles (comme les hooks d’affichage).
2. Le mode d’envoi : privilégiez un transport asynchrone (file de messages ou curl_multi non bloquant) plutôt qu’un envoi synchrone qui retarderait la réponse HTTP.
3. Le volume de commandes quotidien : sur une boutique à faible trafic, un taux de 1.0 reste supportable ; sur une boutique à fort volume, chaque milliseconde ajoutée se multiplie par le nombre de transactions par seconde.

Sur un tunnel de paiement, le monitoring ne doit jamais coûter plus cher en performance que le problème qu’il est censé détecter. Un échantillonnage contextuel bat toujours un taux fixe.

En résumé

Sentry Performance apporte une visibilité précieuse sur les transactions critiques d’une boutique WooCommerce, mais son coût par défaut n’est pas neutre sur le checkout. En passant d’un taux fixe à un échantillonnage contextuel via traces_sampler, il est possible de conserver une couverture suffisante pour détecter les régressions tout en ramenant le surcoût de 340 ms à moins de 60 ms sur la page la plus sensible du site. La règle à retenir : mesurer avant d’activer, puis ajuster l’échantillonnage zone par zone plutôt que globalement.