Chargement
Optimisation mesurée de back-ends sous trafic réel : latence, débit et cold starts.
Le travail de performance commence par la mesure, pas par l'opinion. Sur l'API d'une marketplace, nous avons réduit le cold start des Lambdas d'environ 8 secondes à environ 1,5 en introduisant le bundling esbuild, en élaguant les dépendances et en chargeant les clients SDK à la demande ; il a réécrit les requêtes MySQL les plus lentes derrière des listings de commandes volumineux ; et il a remplacé une opération qui prenait des heures par des scripts Painless mettant à jour des milliers de documents OpenSearch en quelques minutes. La méthode est toujours la même : profiler, corriger le plus gros coût, prouver le gain, recommencer.
Profiler le vrai système sous du vrai trafic. Les chiffres d'abord.
La requête la plus lente et l'endpoint le plus lourd d'abord, pas le plus intéressant.
Un changement à la fois, chacun vérifié contre la référence.
Des alertes et des budgets pour attraper la régression avant vos utilisateurs.
Par mesurer où part le temps : profiling et tracing avant tout changement de code. Le goulot d'étranglement est rarement là où l'intuition le place.
En général, oui, et nettement : bundling, élagage des dépendances et chargement à la demande ont fait passer les services concernés d'environ 8 s à environ 1,5 s.
C'est souvent le même travail : des bundles plus petits, moins d'invocations inutiles et des ressources bien dimensionnées réduisent à la fois la latence et la facture.
La suite de tests tourne sur chaque optimisation, et les réécritures risquées reçoivent d'abord des tests de caractérisation.
Dites-nous sur quoi vous travaillez. Réponse sous 24 heures, diagnostic d'une page sous 48.