Comprendre et gérer la latence dans APISIX : Un guide technique complet

Une question fréquente des utilisateurs concerne la mesure précise de la latence dans APISIX. Lors de l'utilisation d'APISIX, comment doit-on aborder une latence anormalement élevée ?

En réalité, les discussions sur la mesure de la latence se concentrent sur les performances et le temps de réponse des requêtes API. Comprendre ces aspects est crucial pour garantir des services API efficaces, en particulier dans les logiciels B2B où les clients exigent une disponibilité et des performances élevées des API. Dans des scénarios sensibles comme les logiciels de trading boursier dans les marchés financiers, la latence peut avoir un impact significatif sur les traders.

Alors, qu'est-ce que la latence et qu'est-ce que la latence dans APISIX ? La latence dans APISIX fait référence au temps nécessaire pour l'ensemble du processus d'une requête API, depuis son envoi par le client jusqu'à la réception de la réponse. Ce délai comprend des facteurs tels que la latence du réseau client, le temps de traitement interne d'APISIX et la latence d'interaction avec les services en amont.

Pour mieux comprendre et mesurer ces latences, nous pouvons les catégoriser en plusieurs composants clés.

1. Latence réseau entre le client et APISIX : Cela mesure le temps nécessaire pour qu'une requête voyage du client à APISIX, influencé par des facteurs tels que la distance entre le client et APISIX, la congestion du réseau, etc. Des outils spécialisés peuvent être utilisés pour mesurer ce temps.

2. Temps de traitement interne d'APISIX : Cela englobe le temps qu'APISIX prend pour exécuter diverses opérations en interne, y compris les décisions de routage, l'authentification, l'autorisation et la logique personnalisée implémentée via des plugins.

3. Latence d'interaction avec les services en amont : Si APISIX communique avec des services en amont (généralement des applications backend ou des microservices), le temps passé dans cette interaction est inclus dans la latence globale. Cela implique le temps nécessaire pour que la requête voyage d'APISIX au service en amont et le temps que prend la réponse pour revenir.

La latence d'APISIX peut être calculée à l'aide de la formule : Latence d'APISIX = Latence totale - Latence d'interaction en amont. La latence totale représente le temps entre l'envoi de la requête et la réception de la réponse, tandis que la latence d'interaction en amont se concentre sur le temps de communication entre APISIX et le service en amont.

Remarque : Sur Linux, upstream_response_time est compté via clock_gettime(CLOCK_MONOTONIC_COARSE), et avec des valeurs typiques de CONFIG_HZ=250, il peut aller jusqu'à 4 millisecondes. En même temps, le temps pour calculer request_time n'est pas un temps monotone, mais le résultat de gettimeofday(), qui est le temps selon l'horloge murale. Donc, dans certains cas, upstream_response_time peut être légèrement supérieur à request_time.

De plus, dans des environnements réseau faibles ou des scénarios impliquant des téléchargements/upload de fichiers volumineux, la latence entre le client et la passerelle peut être ajoutée à la apisix_latency. Veuillez analyser les problèmes spécifiques au cas par cas.

La latence d'APISIX peut être classée en trois types :

1. Latence en aval : Inclut la latence de transmission réseau et des opérations comme la lecture du corps de la requête entre APISIX et le client. La surveillance et l'analyse de cette latence fournissent des informations sur les performances de communication pour l'optimisation.

2. Latence NGINX : Comme APISIX utilise NGINX pour la gestion et le routage des requêtes, le temps d'exécution interne de NGINX affecte la latence globale. Des outils spécialisés peuvent être utilisés pour la surveillance.

3. Latence d'exécution du code des plugins Lua : Étant donné qu'APISIX dispose de nombreux plugins Lua, le temps d'exécution de chaque plugin est un facteur significatif. Des outils spécialisés sont nécessaires pour l'analyse.

Pour résoudre les problèmes de latence, une analyse systématique peut être menée en fonction des composants de latence identifiés. Les solutions incluent l'optimisation de l'architecture réseau, l'utilisation de CDN pour la latence réseau client, l'identification du code Lua problématique dans APISIX et l'examen des interactions avec les services en amont pour détecter d'éventuels problèmes. Une surveillance et une analyse continues permettent de détecter et de résoudre rapidement les problèmes potentiels, facilitant une meilleure optimisation des services API pour répondre aux exigences des clients finaux.

Comprendre et gérer la latence d'APISIX est essentiel pour garantir des performances API optimales. Grâce à une analyse approfondie de chaque composant, une surveillance continue et une optimisation stratégique, les services API peuvent être améliorés pour accroître la disponibilité et la réactivité, répondant ainsi efficacement aux besoins des utilisateurs finaux.

Pour les données de comparaison de QPS et de latence entre APISIX et d'autres produits de passerelle, consultez "Pourquoi Apache APISIX est-il la meilleure passerelle API ?".