Les performances d’un service Go dépendent de la charge de travail, du volume de données, des dépendances et du matériel. Les chiffres de QPS et de latence n’ont de sens qu’avec une description de test reproductible. Ce guide de planification explique quoi mesurer et comment examiner une proposition d’optimisation ; il ne garantit ni un débit ni un temps de réponse.
Définir la charge de travail avant la cible
| Entrée | À consigner dans le plan de test | Pourquoi c’est important |
|---|---|---|
| Trafic | Répartition des requêtes, utilisateurs simultanés, pics et durée du test | Un seul endpoint mis en cache ne représente pas le produit |
| Données | Taille du jeu de données, forme des requêtes et état du cache | Les petits jeux de données ou les caches préchauffés peuvent masquer les limites de la base de données |
| Environnement | CPU, mémoire, réseau et dépendances externes | Les résultats ne peuvent pas être transférés d’un environnement à un autre sans modification |
| Résultat | Latence par centile, taux d’erreur, débit et utilisation des ressources | La latence moyenne masque les requêtes lentes et les échecs |
Mesurer le goulot d’étranglement
Utilisez le profilage pour examiner le CPU, les allocations et les blocages, ainsi que les traces pour suivre le temps passé au fil d’une requête. Les attentes de connexions à la base de données, les requêtes lentes et les API externes peuvent être dominantes même lorsque l’utilisation du CPU de l’application est faible. Le profilage entraîne une surcharge ; documentez donc son utilisation et comparez les résultats dans des conditions cohérentes. Consultez le guide officiel des diagnostics Go.
Appliquer une modification à la référence
Les modifications possibles incluent l’indexation des requêtes, la concurrence limitée, les délais d’expiration du contexte, le réglage du pool de connexions ou la mise en cache. Indiquez le mécanisme attendu, les règles d’invalidation et le comportement en cas d’échec. Comparez chaque modification à la référence avec la même charge de travail ; ne conservez une modification que lorsque le comportement et les performances visés s’améliorent simultanément.
Demander une évaluation des performances du backend
Préparez les endpoints concernés, le trafic observé, des échantillons de latence et d’erreurs, la taille de la base de données, les limites de l’hébergement et toute méthode de test utilisée précédemment. Supprimez les identifiants et les données personnelles des traces. Découvrez le développement de backends et de systèmes métier ou envoyez un brief d’évaluation des performances. Convenez de critères d’acceptation mesurables et d’un plan de retour arrière avant l’implémentation.