Les requêtes lentes dans l'API Gateway affectent-elles les autres requêtes ?

Une préoccupation fréquemment discutée dans le domaine des passerelles API est la capacité à gérer efficacement un nombre important de requêtes simultanées. Plus précisément, la question se pose : les requêtes lentes augmenteront-elles de manière significative le temps de réponse des autres requêtes normales dans la passerelle API ?

La réponse est que APISIX excelle dans ce domaine, démontrant que les requêtes lentes n'ont pas d'impact négatif sur les autres requêtes normales. Cependant, pour les produits de passerelle API basés sur différents langages et architectures logicielles, les performances peuvent ne pas être aussi favorables.

Divers langages de programmation présentent des degrés variables d'affinité envers les architectures logicielles concurrentes. Les premiers langages de programmation tels que C et Fortran, conçus principalement pour les systèmes à processeur unique, offrent un support limité pour la concurrence. Cependant, avec l'avènement des environnements multiprocesseurs et multithreads, des langages plus récents comme Java et Python intègrent des capacités de concurrence et de traitement parallèle plus robustes. Des langages comme Go ont même été conçus en tenant compte de la concurrence, intégrant étroitement leurs modèles de concurrence avec les fonctionnalités du langage. Le support de la concurrence dans un langage de programmation reflète non seulement l'environnement technologique lors de sa création, mais anticipe également ses scénarios d'application prévus.

En supposant des milliers de requêtes simultanées, l'utilisation d'une architecture multithread ou multiprocessus (comme dans Java ou Python) nécessite l'allocation de milliers de threads ou processus pour gérer les contextes de requête. Ceux qui sont familiers avec la programmation informatique comprennent que, même si une majorité de threads reste inactive, le système d'exploitation consomme des ressources matérielles pour maintenir des milliers de threads ou processus. Cependant, en utilisant des coroutines (comme dans APISIX et Golang), des threads ou processus supplémentaires ne sont pas nécessaires malgré une augmentation des requêtes simultanées.

Les coroutines, threads et processus représentent tous des approches pour le multitâche, mais présentent des différences clés :

1. Mécanisme de planification : La planification des threads/processus est préemptive et gérée par le système d'exploitation (OS), ce qui signifie que l'OS décide quand interrompre et passer à un autre thread ou processus. Inversement, la planification des coroutines est coopérative, pilotée explicitement par les programmeurs ou les bibliothèques de langage. Les coroutines doivent explicitement abandonner le contrôle pour faciliter le passage à d'autres coroutines.

2. Surcharge : Les threads/processus, étant au niveau du système d'exploitation, nécessitent plus de ressources pour leur création, commutation et terminaison. Inversement, les coroutines opèrent dans l'espace utilisateur, entraînant une surcharge relativement moindre pour leur création, commutation et terminaison.

3. Partage et synchronisation des données : Le partage de données entre threads/processus nécessite des opérations de synchronisation complexes, telles que des verrous mutex, des verrous de lecture-écriture, des sémaphores, etc., pour éviter les conditions de course. Les coroutines, étant dans le même thread, peuvent partager directement des variables globales sans avoir besoin d'une synchronisation complexe.

Dans le monde d'APISIX, les requêtes lentes impliquent simplement d'attendre les réponses en amont, un processus limité à l'écoute des événements réseau sans entraîner de surcharge supplémentaire des ressources système. En conclusion, APISIX ne compromet pas le temps de réponse des autres requêtes normales en raison du temps de réponse prolongé de certaines requêtes.