Comparer un même parcours
Exemple fictif en kilooctets décimaux : le parcours initial appelle 100 fois une réponse de 100 kB ; le candidat appelle 20 fois une réponse de 50 kB. Le volume passe de 10000 à 1000 kB, soit 90 % de moins. Cela ne prouve pas une baisse identique de la latence. Le calcul porte uniquement sur les corps des réponses, hors requêtes et en-têtes.
| Mesure fictive | Initial | Candidat |
|---|---|---|
| Appels | 100 | 20 |
| Volume par réponse | 100 kB | 50 kB |
| Volume total | 10000 kB | 1000 kB |
| Durée du parcours | À mesurer | À mesurer |
Réduire avant de paralléliser
- Ne demandez que les champs utiles et parcourez les pages selon le contrat. Un lot doit préciser les résultats partiels et les limites ; une taille de page plus grande n’est pas toujours plus rapide.
- Réutilisez les connexions et les réponses lorsque leur contexte et leur fraîcheur le permettent. Limitez la concurrence et mesurez aussi le coût serveur et les files d’attente.
- Fixez un délai total et un nombre maximal de tentatives. Pour une panne transitoire, espacez les reprises avec une part aléatoire ; vérifiez les reprises déjà présentes dans les différentes couches.
Éviter de refaire une action déjà exécutée
Une expiration côté client ne démontre pas l’annulation côté serveur. Avant de répéter une création ou un paiement, consultez l’état et le mécanisme d’idempotence prévu par le fournisseur. Comparez ensuite durée du parcours, erreurs et exactitude des données sur une charge représentative.
Références primaires
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Appels API : examiner le travail derrière la réponse
Une requête GraphQL unique peut déclencher de nombreux appels en aval. La latence affichée au client cache alors le coût des résolveurs, listes et relations parcourues.
- Tracer une opération du client jusqu’aux services appelés.
- Comparer coût des champs et volume réellement utile.
- Limiter listes et requêtes répétées avant de mettre en cache.
Référence primaire : OWASP — GraphQL Cheat Sheet. Méthode connexe : consulter le guide pratique.
Retry-After : attente, budget et décision de reprise
Réduire les appels inclut la maîtrise des répétitions
Une optimisation API doit compter les tentatives qui atteignent réellement la dépendance, pas seulement les requêtes déclenchées par l’écran.
- Tracer les reprises du SDK et du proxy avec un identifiant logique commun.
- Appliquer une attente qui ne raccourcit pas l’instruction serveur pour tenir artificiellement le budget.
- Faire vérifier l’état d’une écriture incertaine avant de créer une nouvelle intention.
Explorer Retry-After et le modèle de reprise →
Références relues le · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS