Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info
Les requêtes API effectuées par les applications clientes transitent par divers composants d'Apigee Edge avant d'atteindre les services backend. La plupart des applications clientes s'attendent à ce que les réponses à ces requêtes soient reçues dans les meilleurs délais.
Pour obtenir des réponses rapides, les valeurs d'expiration des E/S sont définies dans chacun des composants par lesquels les requêtes API transitent. Si l'un des composants du flux prend plus de temps que le composant précédent, le composant précédent expire et renvoie des erreurs de délai avant expiration de la passerelle 504.
Lors de la configuration du délai avant expiration, les valeurs doivent être configurées dans chacun des composants avec le plus grand soin, sinon cela peut entraîner des erreurs 504 - Expiration du délai de passerelle.
Ce document décrit les bonnes pratiques à suivre pour configurer le délai avant expiration des E/S sur différents composants par lesquels les requêtes d'API transitent dans Apigee Edge.
Bonnes pratiques pour configurer le délai avant expiration des E/S
Tenez compte des bonnes pratiques suivantes lorsque vous configurez le délai avant expiration d'E/S:
- Premier composant:utilisez toujours le délai avant expiration le plus élevé pour le premier composant du flux de requêtes d'API, qui est l'application cliente dans Apigee Edge.
- Dernier composant:utilisez toujours le délai avant expiration le plus court pour le dernier composant du flux de requêtes d'API, qui est le service de backend dans Apigee Edge.
- Entre les composants:assurez-vous qu'il existe une différence d'au moins deux à trois secondes entre la valeur de délai avant expiration configurée dans chaque composant, entre le premier composant 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 le faire sur le routeur. Cela garantit que la nouvelle valeur de délai avant expiration ne s'applique qu'aux proxys d'API qui utilisent l'hôte virtuel spécifique et non à tous les proxys d'API diffusés par le routeur.
Ne configurez (modifiez) le délai avant expiration d'E/S sur le routeur que lorsque vous êtes absolument certain que la nouvelle valeur de délai avant expiration d'E/S est requise ou applicable à tous les proxys d'API exécutés sur le routeur.
- Message Processor (Processeur de messages) : il est toujours recommandé de configurer (modifier) la valeur du délai avant expiration d'E/S pour un proxy d'API spécifique plutôt que de le faire sur le processeur de messages. Cela garantit que la nouvelle valeur de délai avant expiration ne s'applique qu'au proxy d'API spécifique et non à tous les proxys d'API diffusés par le processeur de messages.
Ne configurez (modifiez) le délai avant expiration d'E/S sur le processeur de messages que lorsque vous êtes absolument sûr que la nouvelle valeur de délai avant 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 directement à Apigee Edge à partir d'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'y a pas de composants intermédiaires entre l'application cliente et Apigee Edge, ni entre Apigee Edge et votre serveur backend.
Exemple de configuration Apigee sans composants intermédiaires
Si Apigee Edge est configuré comme indiqué dans le schéma ci-dessus, sans composants intermédiaires, suivez les bonnes pratiques suivantes:
- L'application cliente est le premier composant du flux. La valeur du délai avant expiration le plus élevé 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 bas doit être définie sur le serveur backend.
- Configurez les valeurs de délai avant expiration sur chacun des composants dans l'ordre suivant:
L'exemple suivant montre les 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 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, suivez les bonnes pratiques suivantes:
- L'application cliente est le premier composant du flux. La valeur de timeout la plus élevée doit être définie sur le client.
- Le serveur backend est le dernier composant du flux. La valeur de délai avant expiration la plus faible doit être définie sur le serveur backend.
- Configurez les valeurs de délai avant expiration sur chacun des composants, y compris les composants intermédiaires, dans l'ordre suivant:
L'exemple suivant montre les valeurs de délai avant expiration définies sur les différents composants conformément aux consignes ci-dessus pour éviter tout problème:
