Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Les requêtes API effectuées par les applications clientes transitent par différents composants dans Apigee Edge avant d'atteindre les services de backend. La plupart des applications clientes s'attendent à recevoir les réponses à ces requêtes dans les meilleurs délais.
Pour obtenir des réponses dans les meilleurs délais, les valeurs de délai avant expiration des E/S sont définies dans chacun des composants par lesquels transitent les requêtes API. Si l'un des composants du flux prend plus de temps que le composant précédent, celui-ci expire et renvoie des erreurs 504 de délai avant expiration de la passerelle.
Lors de la configuration du délai avant expiration, veillez à configurer les valeurs avec le plus grand soin dans chacun des composants, sans quoi des erreurs 504 de délai avant expiration de la passerelle peuvent se produire.
Ce document décrit les bonnes pratiques pour configurer le délai d'expiration des E/S sur les différents composants par lesquels les requêtes API circulent dans Apigee Edge.
Bonnes pratiques de configuration du délai d'expiration des E/S
Tenez compte des bonnes pratiques suivantes lorsque vous configurez le délai avant expiration des E/S:
- Premier composant:utilisez toujours le délai avant expiration le plus élevé sur le premier composant du flux de requêtes API, qui est l'application cliente dans Apigee Edge.
- Dernier composant:utilisez toujours le délai d'inactivité le plus bas sur le dernier composant du flux de requêtes API, qui est le service de backend dans Apigee Edge.
- Entre les composants:assurez-vous qu'il existe une différence d'au moins 2 à 3 secondes dans la valeur du délai avant expiration configurée dans chaque composant entre le premier et le dernier composant du flux.
- Routeur:il est toujours recommandé de configurer (modifier) la valeur du délai avant expiration des E/S pour un hôte virtuel spécifique plutôt que de la configurer sur le routeur. Cela garantit que la nouvelle valeur de délai d'expiration n'affecte que les proxys d'API qui utilisent l'hôte virtuel spécifique, et non tous les proxys d'API servis par le routeur.
Configurez (modifiez) le délai avant expiration des E/S sur le routeur uniquement lorsque vous êtes absolument sûr que la nouvelle valeur de délai d'expiration d'E/S est requise ou applicable pour tous les proxys d'API exécutés sur le routeur.
- Processeur de messages:il est toujours recommandé de configurer (modifier) la valeur du délai d'expiration des E/S pour un proxy d'API spécifique plutôt que de la configurer sur le processeur de messages. Cela garantit que la nouvelle valeur de délai d'inactivité n'affecte que le proxy d'API spécifique, et non tous les proxys d'API diffusés par le processeur de messages.
Configurez (modifiez) le délai avant expiration des E/S sur le processeur de messages uniquement lorsque vous êtes absolument sûr que la nouvelle valeur de délai d'expiration d'E/S est requise ou applicable à tous les proxys d'API exécutés sur le processeur de messages.
Exemples de cas de figure
Les scénarios de cette section peuvent vous aider à comprendre comment définir correctement les valeurs de délai avant expiration des E/S.
Scénario 1: Requêtes envoyées à Apigee Edge directement depuis des applications clientes
Cette section décrit les bonnes pratiques à suivre lors de la configuration des valeurs de délai avant expiration dans une configuration Apigee Edge où il n'existe aucun composant intermédiaire entre l'application cliente et Apigee Edge, et entre Apigee Edge et votre serveur backend.
Exemple de configuration d'Apigee sans composant intermédiaire
Si Apigee Edge est configuré comme indiqué dans le schéma ci-dessus, sans composant intermédiaire, suivez les bonnes pratiques suivantes:
- L'application cliente est le premier composant du flux. Le délai avant expiration le plus élevé doit être défini sur le client.
- Le serveur backend est le dernier composant du flux. Le délai avant expiration le plus bas doit être défini sur le serveur backend.
- Configurez les valeurs du délai avant expiration sur chacun des composants dans l'ordre suivant:
L'exemple suivant montre des valeurs de délai avant expiration définies sur les différents composants conformément aux consignes ci-dessus pour éviter tout problème:
Scénario 2: Requêtes envoyées à Apigee Edge à partir d'applications clientes via des composants intermédiaires
Cette section décrit les bonnes pratiques à suivre lors de la configuration des valeurs de délai avant expiration dans une configuration Apigee Edge où il existe un ou plusieurs composants intermédiaires entre l'application cliente et Apigee Edge, ainsi qu'entre Apigee Edge et votre serveur backend.
Les composants intermédiaires peuvent être un équilibreur de charge, un réseau de diffusion de contenu (CDN), NGINX, etc.
Exemple de configuration d'Apigee avec un composant intermédiaire entre le client et Apigee Edge, et entre Apigee Edge et le serveur backend
Si Apigee Edge est configuré comme indiqué dans le schéma ci-dessus, avec un ou plusieurs composants intermédiaires, utilisez les bonnes pratiques suivantes:
- L'application cliente est le premier composant du flux. La valeur la plus élevée de timeout doit être définie sur le client.
- Le serveur backend est le dernier composant du flux. La valeur du délai avant expiration le plus faible doit être définie sur le serveur backend.
- Configurez les valeurs du délai avant expiration sur chacun des composants, y compris les composants intermédiaires, dans l'ordre suivant:
L'exemple suivant montre des valeurs de délai avant expiration définies sur les différents composants conformément aux consignes ci-dessus pour éviter tout problème:
