Comment trouver la seule ligne qui rend un checkout lent.
Quand une boutique en ligne semble lente et que les serveurs sont inactifs, l'attente est en général un appel synchrone vers le système de quelqu'un d'autre, à l'intérieur du chemin de la requête. La méthode qui transforme « ça semble lent » en un fichier et une ligne.
Dans cet article 8 sections
Les plaintes sur une boutique lente sont du genre vague et réputationnel. Pas de stack trace, pas de numéro de ligne, juste un marchand qui rapporte qu'un acheteur l'a dit, et l'arithmétique en dessous : un checkout lent est un panier abandonné, et un panier abandonné est du chiffre d'affaires qui s'en va au milieu de l'achat. Le premier travail n'est donc pas de corriger quelque chose. C'est de transformer une impression en un lieu.
- Mesurez la plateforme sous la charge qui échoue, pas à un moment calme : CPU, load, mémoire, disque, sur chaque niveau. Si chaque niveau est inactif, l'attente vit dans l'application ou dans quelque chose qu'elle appelle.
- Ne faites pas confiance à la page d'accueil en cache. Elle est servie par le CDN et ne prouve rien sur le panier et le checkout, qui exécutent du code applicatif vivant à chaque requête.
- Capturez chaque requête plus lente qu'un seuil et regroupez les stack traces selon l'endroit où chaque requête est bloquée, pas celui où elle a commencé. Un groupe domine tous les autres, et c'est en général un appel synchrone vers un système que la boutique n'exploite pas.
- Remettez le fichier exact, la ligne exacte et le correctif : un timeout court avec un repli, l'appel externe déplacé dans une tâche de fond, et les requêtes en dessous indexées pour qu'elles cherchent au lieu de parcourir.
La plainte arrive comme une impression
La formulation est réputationnelle, pas technique : un acheteur a dit au marchand que le site semblait lent, et le marchand transmet. Pour une boutique, « checkout lent » n'est pas un détail : ce sont des paniers abandonnés à l'étape du paiement, l'endroit le plus coûteux de tout le site pour perdre quelqu'un. Cela cadre l'urgence, mais ne pointe nulle part. Lent est une impression, pas un lieu.
Une alarme de ressources vous dit où regarder. « Le site est lent » ne vous dit rien : ce peut être le réseau, l'hôte, la base de données, l'application, ou un tiers que la boutique n'exploite même pas. Avant de pouvoir le corriger, il faut transformer une impression en numéro de ligne. Le reste de cet article explique comment.
Mesurez d'abord la plateforme sous la charge qui échoue
Commencez par la plateforme, mesurée sous la charge exacte qui échoue : CPU, load average, mémoire libre, utilisation du disque, sur le niveau web et sur la base de données. Lisez-les pendant que la lenteur se produit, pas sur un tableau de bord qui moyenne une semaine calme. Si chaque niveau est inactif, l'attente vit dans l'application ou dans quelque chose qu'elle appelle, et le reste de la méthode consiste à trouver quoi.
C'est là que beaucoup de diagnostics s'arrêtent. « C'est l'application » est vrai et inutile pour un marchand : cela dédouane l'hébergeur et laisse la boutique exactement aussi bloquée qu'avant. Le propriétaire d'une boutique ne veut pas savoir que c'est l'application. Il veut savoir quelle ligne, et pourquoi. La méthode continue donc dans du code qui n'est pas à nous de corriger, parce que trouver la ligne est le véritable livrable.
La page d'accueil va essayer de le cacher
La première chose qu'un contrôle rapide montre paraît rassurante, et c'est le piège. La page d'accueil, en cache sur le CDN, revient vite. Si vous contrôlez une boutique en chargeant sa première page, vous concluez que tout va bien et fermez le ticket. Mais une page d'accueil en cache ne prouve rien sur le checkout, parce que la douleur ne vit que sur les chemins qui ne peuvent pas être mis en cache : le panier dynamique et le checkout, où la boutique exécute son vrai code à chaque requête.
| La page d'accueil en cache | Le chemin du checkout |
|---|---|
| Servie depuis la bordure du CDN | Exécute du code applicatif vivant à chaque fois |
| WHERE THE PAIN LIVESRapide à chaque contrôle rapide | Là où vit réellement chaque seconde de l'attente |
| Paraît parfaitement saine | Jamais touché par un contrôle rapide de la page d'accueil |
Regroupez selon l'endroit du blocage, pas celui du départ
Le geste qui fait tout basculer transforme le bruit en aveu. Au lieu de deviner, capturez chaque requête plus lente qu'un seuil sur tous les nœuds web, puis regroupez les stack traces selon la seule chose qui compte. Pas l'endroit où chaque requête a commencé (elles commencent toutes à une URL), mais la ligne exacte où chaque requête est bloquée, assise à attendre. Regroupez des milliers de requêtes lentes par leur point de blocage et les suppositions s'arrêtent. Un groupe domine tous les autres, et dans une boutique c'est en général un appel sortant vivant vers un système que la boutique n'exploite pas : une vérification de stock, une recherche de prix, un score de fraude, un ERP, à l'intérieur de la validation de commande. Un appel à la base de données alimentant la même intégration est en général le groupe suivant.
Lisez une requête bloquée de haut en bas
La pile d'une requête bloquée montre toute la chaîne, du point d'entrée jusqu'à l'appel externe qu'elle attend : le bouton de paiement en haut, la validation de commande au milieu, et en bas un appel vers une machine sur un autre réseau, où la requête reste jusqu'à ce que cette machine réponde. C'est cette image qu'il faut montrer au marchand, parce qu'elle n'a pas besoin d'interprétation : une personne qui essaie de donner de l'argent à la boutique attend un système que la boutique n'exploite pas avant même que la commande soit validée.
Lisez ensuite la configuration du client pour cet appel. Le plafond de l'attente est une seule ligne : son timeout. Un timeout client réglé en minutes, là où le chemin de paiement a besoin de secondes, signifie qu'un acheteur peut être retenu au bouton de paiement aussi longtemps que le partenaire met à répondre, et la mauvaise journée du partenaire devient celle de la boutique.
“Un acheteur qui essaie de payer attend une machine que la boutique n'exploite pas, sur un réseau que la boutique n'exploite pas, avant même que la commande soit validée.”
Vérifiez les requêtes en dessous
Le slow log de la base de données pointe en général vers la même intégration : les requêtes qui l'alimentent parcourent au lieu de chercher, et elles se trouvent sur le même chemin. L'appel externe est lent, les requêtes en dessous sont lentes, et les deux se tiennent entre l'acheteur et la commande. Corriger l'appel sans les requêtes laisse le second goulet en place.
Nous ne réécrivons pas votre checkout. Nous vous remettons la ligne.
Nous ne réécrivons pas le checkout d'un client : c'est son code, sa logique métier, son risque. Ce que nous remettons est plus utile et plus difficile à obtenir : le fichier exact, la ligne exacte, et le correctif précis. Trois gestes, dans l'ordre.
Plafonnez le timeout
: Ramenez le timeout à quelques secondes avec un repli gracieux, pour qu'un partenaire lent dégrade un chiffre de stock au lieu de figer tout le paiement.
Sortez-le du chemin de la requête
: Déplacez l'appel externe hors de la requête vivante, dans une tâche de fond. Le paiement d'un acheteur ne devrait pas attendre, en direct, la réponse d'un tiers.
Corrigez les requêtes en dessous
: Indexez et réécrivez les requêtes qui alimentent l'intégration, pour que les données derrière elle cessent d'être un second goulet.
- Un appel vivant vers un système externe à l'intérieur de la validation de commande
- Un timeout mesuré en minutes à l'étape du paiement
- L'acheteur qui attend au bouton de paiement
- Des full-table scans exécutés en ligne avec le checkout
- L'appel externe déplacé dans une tâche de fond
- Un timeout de quelques secondes avec un repli gracieux
- Le bouton de paiement répond dans le temps propre de la plateforme
- Les requêtes indexées et réécrites
La leçon
Un serveur sain et inactif n'est presque jamais l'endroit où vit la lenteur. Quand la plateforme est calme et que l'acheteur attend, l'attente est dans le niveau applicatif ou dans quelque chose qu'il appelle, et la méthode ci-dessus trouve quelle ligne.
Gardez les appels synchrones à des tiers hors du chemin de la requête. Donnez aux systèmes externes un timeout court et un repli, et faites le vrai travail dans une tâche de fond. Le chemin de la requête appartient à l'acheteur.
Réponses directes
Pourquoi mon checkout est-il lent alors que le reste du site est rapide ?+
En général parce que la partie rapide est en cache et la partie lente non. Une page d'accueil servie par un CDN répond vite et ne vous dit rien sur le checkout, qui exécute votre code applicatif vivant à chaque requête, y compris tout appel à un tiers placé sur le chemin de paiement. Contrôlez le panier dynamique et le checkout, pas la première page.
Un checkout lent est-il un problème d'hébergement ou d'application ?+
Cela mérite d'être prouvé, pas supposé. Mesurez le niveau web et la base de données sous la même charge réelle : CPU, load, mémoire, disque. Si rien ne manque de ressources, l'attente est dans l'application ou dans quelque chose qu'elle appelle, et l'étape suivante est de capturer les requêtes lentes et de lire où elles bloquent.
Qu'est-ce qu'un appel synchrone à un tiers dans le chemin du checkout ?+
C'est quand votre checkout bloque et attend, en direct, un système externe avant de laisser la commande avancer : un ERP, un service de stock, un score de fraude, vérifiés à l'intérieur de la validation de commande. Si ce partenaire est lent, votre acheteur attend exactement aussi longtemps que lui, jusqu'au timeout configuré, et un timeout réglé en minutes est un plafond mesuré en minutes.
Comment trouvez-vous quelle ligne rend une page lente ?+
Nous capturons chaque requête plus lente qu'un seuil sur tous les nœuds web, puis nous regroupons les stack traces selon la ligne exacte où chaque requête est bloquée, pas celle où elle a commencé. Le plus gros groupe est votre réponse.
Allez-vous corriger mon code pour moi ?+
Nous ne réécrivons pas votre checkout : c'est votre logique métier. Nous vous remettons le fichier exact, la ligne exacte et le correctif précis : raccourcissez le timeout avec un repli, déplacez l'appel au tiers dans une tâche de fond, et nous indexerons et réécrirons les requêtes lentes en dessous. Le diagnostic, livré avec précision, est le produit.
Un bouton de paiement doit-il appeler directement un ERP ou un autre tiers ?+
Gardez-le hors du chemin de la requête. Un système sur une infrastructure que vous ne contrôlez pas ne devrait pas se tenir entre l'acheteur et le paiement. Donnez-lui un timeout court et un repli gracieux pour qu'il puisse échouer sans faire tomber le checkout, et déplacez le vrai appel dans une tâche de fond.
Quelque chose dans votre checkout est lent. Nous trouverons la ligne.
Parlez à un ingénieur qui lira votre chemin lent jusqu'au fichier et à la ligne, et le dira clairement quand la réponse vit dans votre propre code.
Parler à un ingénieurLa discipline ici est la même que derrière deux autres lectures : comment dimensionner un serveur, où la plupart des gens ont besoin de moins qu'ils ne le pensent, et pourquoi un nouveau serveur paraît plus lent que l'ancien alors qu'il ne l'est pas.
Vous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur