• Partager cette lettre Et je vous envoie quelques récompenses pour les références.

Comment accélérer votre API ?

Chaque demande nécessite du travail... Pars la charge utile, interroge la base de données, emballe la réponse, puis renvoie-la. Chaque étape prend du temps...

À mesure que le trafic augmente, ces petits retards s'additionnent :

• Les serveurs luttent sous charge,

• Les utilisateurs attendent plus longtemps les réponses,

• Les coûts augmentent en ajoutant plus de machines.

La solution n'est PAS d'écrire un code plus rapide.

Au lieu de cela, construire des systèmes plus intelligents qui font moins de travail, gérer plus de trafic, et rester rapide sous la pression.

Laissez plonger dans des façons éprouvées de construire des API haute performance...

Chapitre

Chapitre

Voici ce qui se trouve dans cette newsletter:

• Pourquoi la latence augmente même lorsque votre code est efficace. Les goulets d'étranglement réels se cachent dans les bases de données, les réseaux et les services en aval, et pourquoi l'échelle d'une API consiste principalement à réduire le travail inutile.

• Les modèles d'architecture derrière les API haute performance. Qu'est-ce que la mise en cache, le traitement asynchrone, la mise en commun des connexions, l'équilibrage des charges, la limitation des vitesses et les disjoncteurs résolvent chacun, et pourquoi les systèmes de production les combinent au lieu de compter sur une seule optimisation.

• Chaque optimisation a un mode de défaillance. Pourquoi les caches, l'épuisement de la piscine, les tempêtes de réessayer, le ballonnement de charge utile et l'autoscalage mal réglé peuvent réduire la fiabilité tout en essayant d'améliorer les performances.

• Votre API est aussi rapide que sa dépendance la plus lente. Pourquoi les bases de données, les services externes, les voyages en réseau et les charges utiles inefficaces dominent généralement la latence de la demande de bout en bout, bien avant que votre code d'application devienne le goulot d'étranglement.

• Neuf invites à revoir votre architecture API. Les goulets d'étranglement de latence d'audit, l'accès à la base de données, la stratégie de mise en cache, l'état de préparation à l'échelle, l'observabilité et la résilience pour identifier les améliorations de performance à impact élevé avant que le trafic ne révèle des points faibles.

Chapitre

1. Cachage et compression

Si les réponses n'ont pas changé, vous devriez STOP les recalculer.

C'est l'idée centrale derrière cache: stocker les réponses afin de les réutiliser plus tard. Cela saute les opérations coûteuses telles que les requêtes de base de données, la manipulation de données et/ou les appels API.

Voici comment ça marche :

1. Votre API reçoit une demande X pour la première fois

   • Il effectue les étapes habituelles : analyse, requête de la base de données, paquet dans une réponse Y, et envoie la réponse

   • Juste avant/après l'envoi, il stocke Y quelque part dans la mémoire; Y est maintenant une réponse mise en cache à la demande X

2. Votre API reçoit une demande X pour la deuxième fois

   • Il vérifie d'abord le cache et voit que la réponse Y est déjà là, donc il la retourne; c'est un bouton cache

   • Il est beaucoup plus rapide parce qu'il n'y avait pas de requêtes de base de données, d'appels API ou de manipulation de données

3. Mais que se passe-t-il quand la réponse à X n'est plus Y ?

   • Si le cache sert des données périmées, vos utilisateurs voient Résultats inexistants (c'est mauvais)

   • Votre API doit supprimer les données statiques et les mettre à jour avec une nouvelle copie. invalidation du cache

   • Il existe différentes techniques d'invalidation : time-to-live (TTL), suppression manuelle, en-têtes cache-control

La mise en cache est utile pour les données qui ne changent PAS souvent.

Pensez à des demandes comme des recherches de profil ou de catalogue de produits. Les implémentations populaires sont des caches en mémoire (Redis, Memcaché) et caches de bord (Rapidement, Nuageux) .

Descendants de la mise en cache

• Données stales : cache peut servir des réponses dépassées si l'invalidation n'est pas bien gérée

• Complexité : la logique d'invalidation ajoute une logique supplémentaire quand supprimer/ rafraîchir les entrées

• Difficile à déboguer : le comportement dépend du timing, pas seulement de la logique du code

Compression expliquée

Si les réponses sont trop grandes, les réduire.

C'est l'idée centrale derrière compression: réduire la charge utile avant de l'envoyer sur le réseau. Il supprime redondance, comme les caractères répétés ou le formatage. Un résultat plus petit mais égal voyage plus rapidement et utilise moins de bande passante.

Voici comment ça marche :

1. Votre API et le client conviennent du format de compression à utiliser

   • Ce processus se produit souvent à travers le Accept-Encoding et Content-Encoding En-têtes HTTP

   • Par exemple, un client demande Accept-Encoding: gzip, et les réponses API avec Content-Encoding: gzip

2. Votre API prépare les données de réponse Y

   • Avant d'envoyer, il exécute Y à travers un algorithme de compression

   • Cela rend Y plus petit, donc il utilise moins de bande passante réseau et est envoyé plus rapidement

3. La version plus petite et compressée de Y est envoyée sur le réseau

4. Client reçoit cette version compressée de Y

   • Avant de l'utiliser, le client exécute la réponse à travers un algorithme de décompression

   • Cela lui fait grandir à sa taille originale à nouveau

La compression fonctionne bien pour les grandes réponses JSON/binary.

Certains formats de compression populaires sont Gzip et Brotli. D'autres options sont utilisées Protobuf ou Avro formats qui réduisent la taille de la charge utile par conception.

En dessous de la compression

• Coût du processeur: chaque cycle encode/décode consomme de la puissance de traitement

• Uniquement utile pour les charges utiles importantes: mieux utilisé lorsque les réponses dépassent 1Ko

• Diminuer les rendements : pour les petites réponses, le coût du processeur pourrait dépasser les économies de réseau

A emporter

• La mise en cache évite la recomputation et permet d'économiser du temps de traitement, mais ajoute un coût de mémoire et une complexité d'invalidation.

• La compression réduit la taille de la charge utile et la latence du réseau, mais augmente l'utilisation du processeur.

Les deux accélèrent votre API lorsqu'elle est utilisée sélectivement et mesurée par rapport à leurs compromis.

Chapitre

2. Équilibrage et calibrage automatique des charges

Comment maintenez-vous votre API rapidement à mesure que la demande augmente?

Chaque demande que votre API obtient est un .

À mesure que le trafic augmente, une machine ne peut pas tout faire. Le système ralentit, les files d'attente se forment et les utilisateurs attendent. Ajouter plus de serveurs aide, mais seulement si vous pouvez partager le travail et les gérer correctement.

C'est ce que font l'équilibrage de charge et l'échelle automatique.

Partager

Équilibrage des charges expliqué

Si un serveur est occupé, vous devriez diriger de nouvelles requêtes vers d'autres serveurs.

C'est l'idée clé derrière équilibre de charge. Il diffuse le trafic entrant sur de nombreux serveurs de sorte qu'aucun ne soit coincé à faire tout le travail. C'est comme un flic qui dirige les voitures vers les voies ouvertes.

Voici comment ça marche :

1. Votre API reçoit une demande

2. L'équilibreur de charge se trouve devant tous les serveurs et décide où il va

3. Il vérifie quels serveurs sont sains et à quel point ils sont occupés

4. Charger l'équilibreur envoie la demande à la meilleure option

5. Ce serveur le gère et retourne la réponse

L'équilibrage des charges rend votre système plus rapide et plus fiable.

Si un serveur échoue ou est dépassé, d'autres prennent le relais. L'équilibrage des charges est idéal pour les API web, les microservices et les systèmes à forte circulation. Vous en construisez rarement vous-même, mais utilisez des solutions existantes.

Certaines implémentations populaires sont AWS ELB, HAProxyet Nginx.

Abaisse de l'équilibrage de la charge

• Configuration des frais généraux: ajoute le travail de configuration et de gestion

• Point unique d'échec: peut devenir un sans redondance

• Problèmes de session : des sessions d'état s'interrompent lorsque les requêtes vont à différents serveurs

• Plus de complexité: sessions collantes / sessions de réparation de stockage partagé, mais ajouter de la complexité

Autoscalage expliqué

Si les serveurs ne peuvent pas suivre, vous ne devriez pas ajouter plus manuellement ; laissez le système le faire pour vous.

C'est l'idée derrière autotarification. Il ajoute/supprime automatiquement les serveurs lorsque la charge change. C'est comme appeler des chefs supplémentaires quand un restaurant reçoit une rafale de commandes, puis les renvoyer à la maison quand il se calme.

Voici comment ça marche :

1. Système suit des paramètres tels que CPU, mémoire et/ou taux de requête

2. Lorsque le trafic devient élevé, il ajoute plus de serveurs basés sur des règles prédéfinies

3. Nouveaux serveurs rejoignent et commencent à prendre des requêtes

4. Lorsque le trafic baisse, des serveurs supplémentaires s'arrêtent

5. Le système reste stable & ne gaspille pas l'argent

L'automatisation est courante dans les systèmes avec des charges de travail imprévisibles et des pics de trafic.

Les outils populaires sont Kubernetes HPA & Groupes de calibrage automatique AWS.

En dessous de l'échelle automatique

• Sensibilité aux règles : déclencher des déchets trop tôt, tout en déclenchant trop tard nuit aux performances

• Délais de démarrage: le démarrage lent du serveur affecte les performances lors de l'échelle

• Travail de configuration : nécessite l'accordage des règles et seuils de déclenchement

A emporter

L'équilibrage de charge s'étend sur les serveurs et empêche la surcharge.

Autoscaling ajoute/supprime des serveurs dans le système et gère la capacité du système. Ensemble, ils rendent les API plus rapides, stables et prêtes pour les changements de trafic.

Chapitre

3. Traitement asynchrone

Comment maintenez-vous votre API réactive lorsque certaines tâches prennent du temps ?

Les tâches comme l'envoi de courriels, la lecture de fichiers ou les services d'appel passent beaucoup de temps à attendre les entrées/sorties (Autres) .

Pendant l'attente, le serveur n'utilise pas efficacement le processeur. Si votre API attend la fin de ces longues tâches, les utilisateurs éprouvent un temps de réponse lent. Traitement asynchrone Résoudre ce problème. Il permet à l'API de réagir immédiatement pendant que les tâches lourdes s'exécutent en arrière-plan.

Voici comment ça marche :

1. API reçoit une requête qui déclenche une tâche liée aux OI

2. Au lieu de le traiter immédiatement, il met un message dans une file d'attente

3. L'API répond immédiatement au client avec un ID/status d'emploi

4. Les travailleurs de base lisent de la file d'attente et traitent les tâches indépendamment

5. Les travailleurs informent le client lorsque le travail est fait (OPTIONNEL)

Il aime passer commande dans un restaurant et recevoir un buzzer:

Vous pouvez continuer à faire d'autres choses pendant que la cuisine termine votre repas, et le restaurant continue de servir de nouveaux clients.

Le traitement asynchrone est idéal pour les systèmes à forte circulation, les charges de travail imprévisibles ou les tâches d'OI lentes. Il découple la manipulation des demandes de travail lourd, en maintenant les API rapides et réactives.

Les outils populaires sont LapinMQ, Kafka & Céleri.

Défauts du traitement asynchrone

• Plus grande complexité : gérer les files d'attente, les travailleurs, les relevés et le suivi des erreurs

• Débogage plus dur: l'exécution se produit en dehors du flux de requête principal

• Manipulation des défaillances: les travailleurs qui échouent doivent réessayer/reprendre les tâches

• Prestation CPU limitée: offre peu d'aide pour le travail lié CPU où l'attente n'est pas le problème

A emporter

Le traitement asynchrone maintient les APIs réceptives en déchargeant les tâches d'OI lentes aux travailleurs de fond.

Il échange la simplicité pour l'évolutivité, rendant les systèmes plus rapides sous charge mais plus difficiles à surveiller et à déboguer.

Chapitre