Vous avez créé une API, elle fonctionne, mais les utilisateurs se plaignent de la lenteur des réponses. Vous regardez le code, tout semble normal. La base de données fonctionne, les requêtes sont simples, mais le temps de réponse est toujours en secondes, et non en millisecondes. Une situation familière ?
Le problème est que la plupart des développeurs vérifient les choses évidentes : les index dans la base de données, la complexité des algorithmes, la taille des données. Mais les vrais freins se cachent souvent dans des endroits où peu de gens regardent. Analysons 12 raisons non évidentes de la lenteur de l'API.
1. Requêtes DNS pour chaque appel externe
Votre API fait appel à un service externe : un système de paiement, un service d'analyse ou un autre microservice. Et à chaque fois, il effectue une requête DNS pour connaître l'adresse IP. Cela peut ajouter 20 à 200 millisecondes à chaque requête.
De nombreux clients HTTP ne mettent pas en cache le DNS par défaut. Si votre API effectue 10 requêtes externes pour une requête utilisateur, vous perdez jusqu'à 2 secondes uniquement sur le DNS.
Solution : configurer la mise en cache DNS dans le client HTTP ou utiliser le connection pooling avec la réutilisation des connexions.
2. Sérialisation des données dans un format inefficace
JSON est pratique, mais lent. Si votre API transfère de grandes quantités de données entre les services, la sérialisation et la désérialisation JSON peuvent prendre une partie importante du temps de traitement de la requête.
Par exemple, la sérialisation d'un tableau de 10 000 objets en JSON peut prendre 50 à 100 millisecondes en Python. Si cela se produit plusieurs fois par requête, le temps s'accumule.
Alternatives : pour les communications internes entre les services, essayez MessagePack, Protocol Buffers ou même un format binaire simple. Ils travaillent beaucoup plus vite.
3. Journalisation synchrone et redondante
Vous enregistrez chaque demande, chaque réponse, chaque action. C'est correct pour le débogage, mais si les journaux sont écrits de manière synchrone dans un fichier ou une base de données, chaque opération d'écriture bloque l'exécution du code.
L'écriture dans un fichier peut prendre 5 à 20 millisecondes. Si vous écrivez 10 journaux par requête, il s'agit déjà de 50 à 200 millisecondes de latence nette.
Solution : utilisez la journalisation asynchrone avec un tampon, envoyez les journaux à un processus ou service distinct, réduisez le niveau de détail en production.
4. Absence de requêtes préparées pour la base de données
Même avec des index, la base de données peut fonctionner lentement si vous envoyez une nouvelle requête SQL à chaque fois au lieu d'utiliser des prepared statements. La base de données est obligée d'analyser la requête à chaque fois, de construire un plan d'exécution et seulement ensuite de l'exécuter.
Les requêtes préparées sont mises en cache par la base de données et la ré-exécution est presque instantanée. Économies — jusqu'à 30-40% du temps pour effectuer des requêtes simples.
5. Démarrages à froid dans les fonctions cloud
Si vous utilisez une architecture sans serveur (AWS Lambda, Google Cloud Functions), un démarrage à froid peut ajouter de 500 millisecondes à plusieurs secondes à la première requête après une période d'inactivité.
Le problème est aggravé si votre fonction est lourde : beaucoup de dépendances, de grandes bibliothèques, une longue initialisation. L'utilisateur voit les freins, bien que le code lui-même fonctionne rapidement.
Solution : utilisez la simultanéité provisionnée pour les fonctions critiques, optimisez la taille de l'image, déplacez l'initialisation en dehors de la fonction de gestionnaire.
6. Absence de pool de connexion à la base de données
Chaque nouvelle connexion à la base de données prend plusieurs dizaines de millisecondes pour établir une connexion TCP, s'authentifier et s'initialiser. Si votre API crée une nouvelle connexion pour chaque requête, vous perdez du temps.
Le pooling de connexions réutilise les connexions existantes. Il s'agit d'une optimisation de base, mais de nombreux développeurs novices l'oublient ou la configurent mal.
Vérifiez les paramètres : y a-t-il suffisamment de connexions dans le pool ? Ne se ferment-elles pas trop vite ? Le délai d'attente est-il correctement configuré ?
7. Le middleware est exécuté pour toutes les requêtes
Vous disposez d'un middleware pour l'authentification, la journalisation, le traitement CORS, la validation. Tout cela est fait pour chaque requête, même pour les fichiers statiques ou le point de terminaison de vérification de l'état.
Si le middleware effectue une requête à la base de données ou à un service externe pour vérifier le jeton, cela ajoute un délai à toutes les requêtes sans exception.
Solution : optimisez l'ordre du middleware, effectuez des vérifications faciles, excluez les chemins inutiles, mettez en cache les résultats de validation des jetons.
8. Garbage Collection à un moment critique
Les langages avec gestion automatique de la mémoire (Python, Java, Go) exécutent périodiquement le ramasse-miettes. Dans la plupart des cas, cela passe inaperçu, mais si votre API accumule beaucoup d'objets en mémoire, le GC peut se déclencher directement pendant le traitement de la requête et geler l'exécution pendant des dizaines ou des centaines de millisecondes.
Ceci est particulièrement visible sur Python avec son GIL et sur Java avec des paramètres GC mal configurés.
Surveillez les pauses GC, ajustez les paramètres du ramasse-miettes, évitez de créer des objets inutiles dans les zones chaudes du code.
9. Opérations de blocage dans le code asynchrone
Vous utilisez async/await, FastAPI ou Node.js, mais quelque part dans le code, vous effectuez un appel synchrone : lecture d'un fichier, requête à la base de données sans pilote asynchrone, appel à l'API via des requêtes régulières.
Cela bloque la boucle d'événements et toutes les autres requêtes sont mises en file d'attente. Une requête lente ralentit l'ensemble du serveur.
Solution : utilisez uniquement des bibliothèques asynchrones, déplacez les opérations de blocage vers un pool de threads ou des processus séparés, vérifiez l'ensemble du code pour les appels synchrones.
10. Absence de timeout sur les requêtes externes
Votre API appelle un service externe, mais ne définit pas de délai d'expiration. Si le service externe est lent ou a cessé de répondre, votre demande est suspendue pendant des minutes jusqu'à ce que le délai d'attente par défaut du système d'exploitation se produise.
L'utilisateur voit un chargement sans fin, et votre API consomme des ressources en attendant une réponse qui peut ne jamais arriver.
Toujours définir des délais d'attente raisonnables : 5 à 10 secondes pour les API externes, 1 à 2 secondes pour les services internes. Il vaut mieux renvoyer une erreur rapidement que de faire attendre l'utilisateur.
11. Retraitement des demandes identiques
L'utilisateur a cliqué plusieurs fois sur le bouton ou le frontend envoie une nouvelle tentative lors de l'expiration. Votre API reçoit les mêmes requêtes et traite honnêtement chacune d'entre elles : elle effectue des requêtes à la base de données, des calculs, l'envoi de lettres.
Non seulement cela est lent, mais cela peut également entraîner des doublons de données et des comportements incorrects.
Solution : utilisez des clés d'idempotence, mettez en cache les résultats des requêtes récentes, bloquez les renvois sur le frontend.
12. Les métriques et la surveillance sont en soi des freins
L'ironie, mais les outils de mesure de la performance peuvent eux-mêmes devenir une source de freins. La collecte de métriques détaillées, le suivi de chaque requête, l'envoi de données aux systèmes de surveillance, tout cela nécessite des ressources.
Si vous collectez trop de métriques ou les envoyez de manière synchrone, cela consomme du temps processeur et ajoute des retards.
Soyez raisonnable : collectez uniquement les métriques nécessaires, utilisez l'échantillonnage pour le traçage, envoyez les données de manière asynchrone et par lots.
Que faire ensuite ?
Vous connaissez maintenant 12 raisons non évidentes pour lesquelles l'API peut ralentir. L'étape suivante est une vérification systématique : ajoutez le profilage, mesurez le temps à chaque étape du traitement de la demande, trouvez les goulots d'étranglement.
Rappelez-vous : la productivité n'est pas une optimisation ponctuelle, mais un processus continu. Surveillez, mesurez, améliorez.
Code n'est pas seulement une application, mais votre mentor personnel dans le monde de la programmation. Il explique tout avec des mots simples, aide à consolider les connaissances dans la pratique et donne des récompenses cool pour les succès 🏅
Et nous avons aussi un super Chaîne Telegram avec une communauté amicale où vous pouvez poser n'importe quelle question et obtenir de l'aide de développeurs expérimentés. Rejoignez-nous !