Cette page a été traduite par l'API Cloud Translation.

504 Expiration du délai de la passerelle

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit un code d'état HTTP 504 avec le message Gateway Timeout en réponse aux appels d'API.

Le code d'état HTTP 504 Gateway Timeout indique que le client n'a pas reçu de réponse rapide de la passerelle périphérique ou du serveur backend lors de l'exécution de une API

Messages d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 504 Gateway Timeout

Dans certains cas, le message d'erreur suivant peut également s'afficher:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Quelles sont les causes des délais avant expiration de la passerelle ?

Le chemin d'accès habituel d'une requête API via la plate-forme Edge est le suivant : Client -> Routeur -> Processeur de messages -> Serveur backend comme illustré ci-dessous:

L'application cliente, les routeurs et les processeurs de messages de la plate-forme Edge sont configurés avec les valeurs de délai d'expiration appropriées. La plate-forme Edge s'attend à ce qu'une réponse soit envoyée dans un certain délai pour chaque requête API en fonction des valeurs de délai avant expiration. Si vous n'obtenez pas la réponse sous pendant la période spécifiée, 504 Gateway Timeout Error est renvoyé.

Le tableau suivant fournit plus de détails sur le moment où les délais d'inactivité peuvent se produire dans Edge:

Occurrence du délai avant expiration	Détails
Le délai d'inactivité se produit sur le processeur de messages	Le serveur backend ne répond pas au processeur de messages dans un délai spécifié. sur le processeur de messages. Le processeur de messages expire et envoie l'état de la réponse `504 Gateway Timeout` au routeur.
Expiration du délai sur le routeur	Le processeur de messages ne répond pas au routeur dans le délai imparti sur le routeur. Le routeur expire et envoie l'état de réponse `504 Gateway Timeout` à l'application cliente.
Le délai d'inactivité se produit au niveau de l'application cliente.	Le routeur ne répond pas à l'application cliente dans le délai spécifié. sur le routeur. L'application cliente expire et met fin à l'état de réponse `504 Gateway Timeout` pour l'utilisateur final.

Causes possibles

Dans Edge, les causes typiques de l'erreur 504 Gateway Timeout sont les suivantes:

Cause	Détails	Pas effectués pour
Serveur backend lent	Le serveur backend qui traite la requête API est trop lent en raison d'une charge élevée ou de mauvaises performances.	Utilisateurs de cloud public et privé
Traitement lent des requêtes API par Edge	Edge met beaucoup de temps à traiter la requête API en raison d'une charge élevée ou d'une mauvaise des performances.

Lente serveur backend

Si le serveur backend est très lent ou prend beaucoup de temps pour traiter la requête API, alors vous obtenez une erreur 504 Gateway Timeout. Comme expliqué dans la section ci-dessus, le délai avant expiration peut se produire dans l'un des scénarios suivants:

Le processeur de messages expire avant que le serveur backend ne réponde.
Le routeur expire avant que le processeur de messages/le serveur backend ne réponde.
L'application cliente expire avant que le routeur, le processeur de messages ou le serveur backend ne réponde.

Les sections suivantes expliquent comment diagnostiquer et résoudre le problème sous chacun de ces différents scénarios.

Scénario 1 Le processeur de messages expire avant que le serveur backend ne réponde

Diagnostic

Vous pouvez utiliser les procédures suivantes pour déterminer si l'erreur 504 Gateway Timeout s'est produite en raison de la lenteur du serveur backend.

Procédure n° 1 avec Trace

Si le problème persiste (504 erreurs persistent), procédez comme suit : étapes:

Tracez l'API concernée dans l'interface utilisateur Edge. Attendez que l'erreur se produise ou d'un appel d'API, puis effectuez quelques appels d'API et reproduisez l'erreur 504 Gateway Timeout.
Une fois l'erreur survenue, examinez la requête spécifique qui affiche le code de réponse sous la forme 504
Vérifiez le temps écoulé à chaque phase et notez la phase où le plus de temps dépensés.
Si vous observez l'erreur avec le temps écoulé le plus long immédiatement après l'une des les phases suivantes, cela indique que le serveur backend est lent ou met beaucoup de temps à traiter la requête: <ph type="x-smartling-placeholder">
- Demande envoyée au serveur cible
- Règle ServiceCallout

Vous trouverez ci-dessous un exemple de trace montrant que le serveur backend n'a pas répondu après 55 secondes, ce qui génère une erreur 504 Gateway Timeout:

Dans la trace ci-dessus, le processeur de messages expire au bout de 55 002 ms, comme le fait le serveur backend. de ne pas répondre.

Procédure n° 2 : utilisation des journaux du processeur de messages

Vérifier le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Si vous trouvez des erreurs Gateway Timeout et onTimeoutRead pour la requête de proxy d'API spécifique à un moment précis, cela indique que le processeur de messages a expiré.

Exemple de journal du processeur de messages montrant une erreur de délai d'inactivité de la passerelle

2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

Dans le journal du processeur de messages ci-dessus, vous remarquez que le serveur backend a indiqué l'adresse IP l'adresse XX.XX.XX.XX n'a pas répondu, même au bout de 55 secondes (lastIO=55 000ms). Par conséquent, le processeur de messages a expiré et a envoyé une erreur 504 Gateway Timeout.

Vérifiez: comment le délai avant expiration est-il contrôlé sur le processeur de messages ?

Comment le délai d'inactivité est-il contrôlé sur le processeur de messages ? Les processeurs de messages sont généralement définie avec un délai avant expiration par défaut de 55 secondes) via la propriété. HTTPTransport.io.timeout.millis La valeur de ce délai est applicable à tous les proxys d'API appartenant à une organisation gérée par ce Processeur de messages.
- Si le serveur backend ne répond pas dans un délai de 55 secondes, le message Le processeur expire et envoie l'erreur 504 Gateway Timeout au client.
La valeur du délai avant expiration spécifiée dans le processeur de messages peut être remplacée par la propriété io.timeout.millis spécifié dans le proxy d'API. Cette valeur de délai avant expiration est applicable à une API spécifique Proxy dans lequel la propriété mentionnée ci-dessus est spécifiée. Par exemple, si le io.timeout.millis est défini sur 10 secondes dans le proxy d'API, puis la valeur du délai avant expiration de 10 secondes sera utilisée pour ce proxy d'API spécifique.
- Si le serveur backend ne répond pas dans un délai de 10 secondes à l'événement proxy d'API, le processeur de messages expire et envoie 504 Gateway Timeout au client.

Solution

Vérifiez pourquoi le serveur backend prend plus de 55 secondes et voyez si cela peut être fixes/optimisées pour répondre plus rapidement.
S'il n'est pas possible de réparer/optimiser le serveur backend ou si l'on sait que le backend le serveur prend plus de temps que le délai d'expiration configuré, puis Augmentez le délai d'inactivité sur le routeur et le processeur de messages à une valeur appropriée.

Scénario 2 : Le routeur expire avant que le processeur de messages/le serveur backend ne réponde

Vous pouvez recevoir des erreurs 504 Gateway Timeout si le délai d'inactivité du routeur est dépassé avant que le message Réponse du processeur/serveur backend. Cela peut se produire dans les cas suivants:

La valeur du délai avant expiration définie sur le routeur est inférieure à celle définie sur l'état Processeur. Par exemple, supposons que le délai d'inactivité sur le routeur soit de 50 secondes, alors que le message Le processeur dure 55 secondes.

Délai d'inactivité sur le routeur	Délai d'inactivité du processeur de messages
50 secondes	55 secondes

La valeur de délai d'attente sur le processeur de messages est remplacée par une valeur de délai d'attente plus élevée en utilisant La propriété io.timeout.millis définie dans la configuration du point de terminaison cible du proxy d'API:

Par exemple, si les valeurs de délai avant expiration suivantes sont définies:

Délai d'inactivité sur le routeur	Délai d'inactivité du processeur de messages	Délai avant expiration dans le proxy d'API
57 secondes	55 secondes	120 secondes

Cependant, io.timeout.millis est défini sur 120 secondes dans le proxy d'API:

<HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

Ensuite, le processeur de messages n'expirera pas au bout de 55 secondes, même s'il a expiré. (55 secondes) est inférieure au délai avant expiration sur le routeur (57 secondes). En effet, la valeur de délai d'inactivité de 55 secondes sur le processeur de messages est remplacée par la valeur de 120 secondes défini dans le proxy d'API. La valeur de délai d'inactivité du processeur de messages pour ce proxy d'API spécifique sera de 120 secondes.

Comme le routeur a une valeur de délai avant expiration inférieure (57 secondes) à celle de 120 secondes définie dans proxy d'API, le routeur expirera si le serveur backend ne répond pas après 57 jours secondes.

Diagnostic

Vérifier le journal d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Si le délai du routeur expire avant que le processeur de messages soit pris en compte, l'état 504 s'affiche. sur les journaux d'accès NGINX pour la requête API concernée et sur le message id de le processeur de messages est défini sur -. Cela est dû au fait que le routeur n'a reçu aucune réponse à partir du processeur de messages dans le délai d'expiration défini sur le routeur.

Exemple d'entrée de journal NGINX affichant une erreur 504 en raison de l'expiration du délai du routeur
Dans l'exemple ci-dessus, notez l'état de 504 sur NGINX, l'ID du message Le processeur est à -, et le temps total écoulé est de 57,001 secondes. Cela est dû au fait que le routeur a expiré après 57,001 secondes et que nous n'avons obtenu aucune réponse du processeur de messages.

Dans ce cas, Broken Pipe exceptions s'affichent dans le message Journaux de l'outil de traitement (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Cette erreur s'affiche, car une fois le délai d'inactivité du routeur dépassé, il ferme la connexion avec le Processeur de messages. Lorsque le processeur de messages termine son traitement, il tente d'écrire au routeur. Comme la connexion au routeur est déjà fermée, vous obtenez Broken Pipe exception sur le processeur de messages.

Cette exception devrait se produire dans les circonstances expliquées ci-dessus. Le résultat l'erreur 504 Gateway Timeout est toujours due au fait que le serveur backend met toujours plus de temps à répondre. et vous devez résoudre ce problème.

Solution

S'il s'agit d'un serveur backend personnalisé, <ph type="x-smartling-placeholder">

Déterminez la raison pour laquelle le serveur backend met beaucoup de temps à répondre et voyez si le problème fixes/optimisées pour répondre plus rapidement.

S'il n'est pas possible de réparer ou d'optimiser le serveur backend, ou s'il s'agit d'un fait connu le serveur backend demande beaucoup de temps, alors augmentez la valeur du délai Routeur et processeur de messages.

Idée: Définissez la valeur du délai d'expiration sur les différents composants dans commande:

Expiration du délai sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité du message Processeur > Délai avant expiration dans le proxy d'API

S'il s'agit d'un serveur backend NodeJS: <ph type="x-smartling-placeholder">
1. Vérifiez si le code NodeJS appelle d'autres serveurs backend et s'il prend beaucoup de temps pour renvoyer une réponse. Vérifiez pourquoi les serveurs backend prennent plus de temps et résoudre le problème le cas échéant.
2. Vérifiez si les processeurs de messages subissent une utilisation élevée du processeur ou de la mémoire: <ph type="x-smartling-placeholder">
  1. Si un processeur de messages sollicite beaucoup le processeur, générez trois fil de discussion dumps toutes les 30 secondes à l'aide de la commande suivante:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Si un processeur de messages consomme beaucoup de mémoire, générez une tas de mémoire dump à l'aide de la commande suivante:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire le CPU et la mémoire:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Surveillez les appels d'API pour vérifier si le problème persiste.
  5. Contactez l'assistance Apigee Edge et fournissez-lui la empreintes de threads, empreintes de la mémoire et journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)pour vous aider rechercher la cause de cette utilisation élevée du processeur/de la mémoire.

Vérification: Comment le délai avant expiration est-il contrôlé pour les serveurs backend NodeJS sur Message ? Processeur

Le serveur backend NodeJS s'exécute dans le processus JVM du processeur de messages. La la valeur de délai avant expiration pour les serveurs backend NodeJS est contrôlée via la propriété http.request.timeout.seconds dans le fichier nodejs.properties. Ce est définie sur 0 par défaut, ce qui signifie que le délai avant expiration est désactivé par défaut pour toutes les Proxys d'API appartenant à une organisation desservie par ce processeur de messages. Ainsi, même si un serveur backend NodeJS prend beaucoup de temps, le processeur de messages n'expire pas.
Toutefois, si le serveur backend NodeJS prend beaucoup de temps et que le temps nécessaire à l'API requête est > 57 secondes, le routeur expire et envoie 504 Gateway Timeout au client.

Scénario 3 : L'application cliente expire avant le routeur/le processeur de messages/le serveur backend répond

Vous pouvez recevoir des erreurs 504 Gateway Timeout si l'application cliente expire avant que le le serveur backend répond. Cette situation peut se produire si:

La valeur du délai avant expiration définie sur l'application cliente est inférieure à celle définie sur routeur et processeur de messages:

Par exemple, si les valeurs de délai avant expiration suivantes sont définies:

Expiration du délai sur le client	Délai d'inactivité sur le routeur	Délai d'inactivité du processeur de messages
50 secondes	57 secondes	55 secondes

Dans ce cas, le temps total disponible pour obtenir une réponse à une requête API via Edge est inférieur ou égal à 50 secondes. Cela inclut le temps nécessaire pour créer une requête API, la requête étant traitée par Edge (routeur, processeur de messages), la requête étant envoyée au serveur backend (le cas échéant), le backend traite la demande et envoie la réponse, Edge traite et de le renvoyer au client.

Si le routeur ne répond pas au client dans les 50 secondes, le client un délai avant expiration et de fermer la connexion avec le routeur. Le client obtient le code de réponse 504

NGINX est alors défini comme code d'état 499 indiquant que le client a fermé la .

Diagnostic

Si l'application cliente expire avant d'obtenir une réponse du routeur, elle fermer la connexion avec le routeur. Dans ce cas, vous verrez un code d’état 499 dans les journaux d'accès NGINX pour la requête API spécifique.
Exemple d'entrée de journal NGINX affichant le code d'état 499
Dans l'exemple ci-dessus, notez que l'état de 499 sur NGINX et le temps total écoulé sont 50,001 secondes. Cela indique que le client a expiré après 50 001 secondes.

Dans ce cas, Broken Pipe Exceptions s'affichent dans le message. Journaux de l'outil de traitement (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Une fois le délai d'expiration du routeur écoulé, il ferme la connexion avec le processeur de messages. Lorsque Le processeur de messages termine son traitement, il tente d'écrire la réponse sur le routeur. Comme la connexion au routeur est déjà fermée, vous obtenez le Broken Pipe exception sur le processeur de messages.
Cette exception est prévue dans les circonstances expliquées ci-dessus. Donc, la cause réelle de l'erreur 504 Gateway Timeout est toujours que le serveur backend met beaucoup de temps à répondre et vous devez résoudre ce problème.

Solution

S'il s'agit de votre serveur backend personnalisé: <ph type="x-smartling-placeholder">

Vérifiez sur le serveur backend pourquoi l'opération prend plus de 57 secondes et voyez si il peut être corrigé et optimisé pour répondre plus rapidement.

S'il n'est pas possible de réparer/optimiser le serveur backend ou si vous savez que le le serveur backend prend beaucoup de temps, augmentez la valeur du délai avant expiration sur routeur et le processeur de messages.

Idée: Définissez la valeur du délai d'expiration sur les différents composants dans commande:

Expiration du délai sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité du message Processeur > Délai avant expiration dans le proxy d'API

S'il s'agit d'un backend NodeJS: <ph type="x-smartling-placeholder">
1. Vérifiez si le code NodeJS appelle d'autres serveurs backend mettre beaucoup de temps à revenir. Vérifiez pourquoi ces serveurs backend prennent plus de temps.
2. Vérifiez si les processeurs de messages subissent une utilisation élevée du processeur ou de la mémoire: <ph type="x-smartling-placeholder">
  1. Si un processeur de messages sollicite beaucoup le processeur, générez trois fil de discussion dumps toutes les 30 secondes à l'aide de la commande suivante:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Si un processeur de messages utilise beaucoup la mémoire, générez une empreinte de la mémoire en exécutant la commande suivante:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire Processeur et mémoire:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Surveillez les appels d'API pour vérifier si le problème persiste.
  5. Contactez l'assistance Apigee Edge et fournissez-lui la empreintes de threads, empreintes de la mémoire et journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)pour les aider rechercher la cause de cette utilisation élevée du processeur/de la mémoire.

Augmenter la valeur du délai avant expiration sur Routeur et processeur de messages

Choisissez soigneusement les valeurs de délai avant expiration à définir sur le routeur et le processeur de messages en fonction vos exigences. Ne définissez pas de valeurs de délai avant expiration arbitrairement élevées. Si vous avez besoin d'aide, contactez Assistance Apigee Edge

Routeur

chown apigee:apigee /opt/apigee/customer/application/router.properties

Créez le fichier /opt/apigee/customer/application/router.properties sur le Routeur, s'il n'existe pas déjà.
Ajoutez la ligne suivante à ce fichier:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
```
Par exemple, si vous souhaitez définir le délai avant expiration sur 120 secondes, définissez-le sur ce qui suit:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
```
Assurez-vous que ce fichier appartient à Apigee:

Redémarrez le routeur:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Si vous possédez plusieurs routeurs, répétez la procédure ci-dessus sur chacun d'eux.

Processeur de messages

Créer le fichier /opt/apigee/customer/application/message-processor.properties sur la machine de traitement des messages, s'il n'existe pas déjà.
Ajoutez la ligne suivante à ce fichier:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Par exemple, si vous souhaitez définir le délai avant expiration sur 120 secondes, définissez-le sur ce qui suit:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Assurez-vous que ce fichier appartient à Apigee:

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

Redémarrez le processeur de messages:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Si vous disposez de plusieurs processeurs de messages, répétez les étapes ci-dessus sur tous les messages Processeurs.

Idée: Définissez le délai d'expiration sur les différents composants dans l'ordre suivant:

Expiration du délai sur le client > Délai d'inactivité sur le routeur > Délai d'inactivité du processeur de messages > Délai avant expiration dans le proxy d'API

Lenteur du traitement des requêtes API par Edge

Si Edge est très lent et/ou prend beaucoup de temps pour traiter la requête API, vous obtiendrez une 504 Gateway Timeout erreur.

Diagnostic

Tracez l'API concernée dans l'interface utilisateur Edge.
Attendez que l'erreur se produise ou, si vous disposez de l'appel d'API, effectuez des appels d'API. et reproduisez l'erreur 504 Gateway Timeout.
Notez que dans ce cas, une réponse indiquant que l'opération a réussi peut s'afficher dans Trace.
1. Le routeur/client expire car le processeur de messages ne répond pas dans le un délai avant expiration spécifié sur le routeur/client (selon le délai d'expiration le plus court). Cependant, le processeur de messages continue à traiter la demande et peut terminer avec succès.
2. De plus, la valeur HTTPTransport.io.timeout.millis définie sur le Le processeur de messages ne se déclenche que s'il communique avec un serveur à un serveur backend. En d'autres termes, ce délai d'inactivité ne se déclenche pas lorsqu'une règle (autre que la règle ServiceAccroche) dans le proxy d'API prend beaucoup de temps.
Une fois que l'erreur s'est produite, examinez la requête spécifique présentant le plus long temps écoulé.
Vérifiez le temps écoulé à chaque phase et notez la phase où le plus de temps dépensés.
Si vous observez le délai le plus long pour l'une des règles autres que le service Règle d'appel, cela indique alors qu'Edge prend beaucoup de temps pour traiter la requête.
Voici un exemple de trace de l'interface utilisateur montrant un temps écoulé très élevé pour une règle JavaScript:
Dans l'exemple ci-dessus, vous remarquez que la stratégie JavaScript prend une quantité anormalement longue d'environ 245 secondes.

Solution

Vérifiez si la règle qui a mis du temps à répondre et si du code personnalisé leur traitement peut prendre beaucoup de temps. S'il existe un tel code, voyez si vous pouvez corriger/optimiser le code identifié.
Si aucun code personnalisé n'est susceptible d'allonger le temps de traitement, vérifiez si le message Les processeurs utilisent beaucoup le processeur ou la mémoire: <ph type="x-smartling-placeholder">
1. Si un processeur de messages sollicite beaucoup le processeur, générez trois fil de discussion dumps toutes les 30 secondes à l'aide de la commande suivante:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Si un processeur de messages utilise beaucoup la mémoire, générez une empreinte de la mémoire en exécutant la commande suivante:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire la capacité du processeur et la mémoire.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Surveillez les appels d'API et vérifiez si le problème persiste.
5. Contacter l'assistance Apigee Edge et fournir le fil de discussion empreintes, empreintes de la mémoire et journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)pour les aider rechercher la cause de cette utilisation élevée du processeur/de la mémoire.

Diagnostiquer les problèmes à l'aide de la surveillance des API

La surveillance des API vous permet d'isoler rapidement les zones problématiques pour diagnostiquer les problèmes d'erreur, de performances, de latence et leur source, telles que les applications de développement, les mandataires d'API, les cibles de backend ou la plate-forme d'API.

Passez en revue un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de l'API Monitoring. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de codes d'état 504 dépasse un certain seuil.