Diese Seite wurde von der Cloud Translation API übersetzt.

504 Gateway-Zeitüberschreitung

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung empfängt den HTTP-Statuscode 504 mit der Nachricht Gateway Timeout als Antwort auf die API-Aufrufe.

Der HTTP-Statuscode 504 Gateway Timeout gibt an, dass der Client keine rechtzeitige Antwort vom Edge-Gateway oder Backend-Server während der Ausführung von eine API

Fehlermeldungen

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 504 Gateway Timeout

In einigen Fällen wird außerdem die folgende Fehlermeldung angezeigt:

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

Was verursacht Gateway-Zeitüberschreitungen?

Der typische Pfad für eine API-Anfrage über die Edge-Plattform ist Client -> Router -> Message Processor -> Back-End-Server, wie in der folgenden Abbildung dargestellt:

Die Clientanwendung, Router und Message Processor innerhalb der Edge-Plattform werden mit geeignete Werte für die Zeitüberschreitung. Die Edge-Plattform erwartet, dass eine Antwort innerhalb eines bestimmten Zeitraums gesendet wird Zeit für jede API-Anfrage basierend auf den Zeitüberschreitungswerten. Erhalten Sie innerhalb dieses Zeitraums keine Antwort innerhalb des angegebenen Zeitraums, dann wird 504 Gateway Timeout Error zurückgegeben.

Die folgende Tabelle enthält weitere Details zu Zeitüberschreitungen in Edge:

Zeitüberschreitung	Details
Zeitüberschreitung beim Message Processor	Backend-Server reagiert nicht innerhalb eines bestimmten Zeitlimits auf den Message Processor Punkt beim Message Processor. Der Message Processor überschreitet das Zeitlimit und sendet den Antwortstatus als `504 Gateway Timeout` an den Router.
Zeitüberschreitung auf Router	Der Message Processor reagiert nicht innerhalb des angegebenen Zeitlimits auf den Router auf dem Router. Der Router überschreitet das Zeitlimit und sendet den Antwortstatus als `504 Gateway Timeout` an die Clientanwendung.
Zeitüberschreitung bei Clientanwendung	Der Router reagiert nicht innerhalb des angegebenen Zeitlimits auf die Clientanwendung Punkt am Router. Die Clientanwendung überschreitet das Zeitlimit und beendet den Antwortstatus mit `504 Gateway Timeout` für den Endnutzer.

Mögliche Ursachen

In Edge sind die typischen Ursachen für den Fehler 504 Gateway Timeout folgende:

Ursache	Details	Angegebene Schritte für
Langsamer Backend-Server	Der Backend-Server, der die API-Anfrage verarbeitet, ist aufgrund hoher Last oder schlechte Leistung.	Nutzer von öffentlichen und privaten Clouds
Langsame API-Anfrageverarbeitung durch Edge	Edge braucht lange Zeit für die Verarbeitung der API-Anfrage aufgrund hoher oder unzureichender Last die Leistung.

Langsam Backend-Server

Wenn der Back-End-Server sehr langsam ist oder die Verarbeitung der API-Anfrage sehr lange braucht, erhalten Sie den Fehler 504 Gateway Timeout. Wie im Abschnitt oben erläutert, kann das Zeitlimit eines der folgenden Szenarien:

Beim Message Processor tritt eine Zeitüberschreitung auf, bevor der Backend-Server antwortet.
Der Router führt eine Zeitüberschreitung durch, bevor der Message Processor/Back-End-Server antwortet.
Bei der Clientanwendung tritt eine Zeitüberschreitung auf, bevor der Router/Nachrichtenverarbeiter/Back-End-Server antwortet.

In den folgenden Abschnitten wird beschrieben, wie Sie das jeweilige Problem jeweils diagnostizieren und beheben. Szenarien durchführen.

Szenario 1 Beim Message Processor tritt eine Zeitüberschreitung auf, bevor der Backend-Server antwortet

Diagnose

Mit den folgenden Verfahren können Sie feststellen, ob der Fehler 504 Gateway Timeout aufgetreten ist. weil der Backend-Server langsam ist.

Verfahren Nr. 1: Trace verwenden

Wenn das Problem weiterhin besteht (504 Fehler treten weiterhin auf), gehen Sie so vor: Schritte:

Verzeichnen Sie die betroffene API in der Edge-Benutzeroberfläche. Warten Sie entweder, bis der Fehler auftritt, oder API-Aufruf, führen Sie dann einige API-Aufrufe aus und reproduzieren Sie den Fehler 504 Gateway Timeout.
Sobald der Fehler aufgetreten ist, prüfen Sie die spezifische Anfrage, in der der Antwortcode als 504
Überprüfen Sie die verstrichene Zeit in jeder Phase und notieren Sie sich die Phase mit der längsten Zeit. ausgegeben haben.
Wenn Sie den Fehler mit der längsten verstrichenen Zeit sofort nach einer der Phasen folgt, zeigt sie an, dass der Back-End-Server langsam ist oder lange die Anfrage zu verarbeiten: <ph type="x-smartling-placeholder">
- Anfrage an Zielserver gesendet
- ServiceCallout-Richtlinie

Im Folgenden finden Sie ein Trace-Beispiel, das zeigt, dass der Backend-Server nicht einmal geantwortet hat nach 55 Sekunden, was zu dem Fehler 504 Gateway Timeout führt:

Im obigen Trace tritt beim Message Processor eine Zeitüberschreitung nach 55.002 ms auf, da der Back-End-Server es tut. nicht antworten.

Prozedur Nr. 2: Message Processor-Logs verwenden

Protokoll des Message Processor prüfen (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Wenn Sie die Fehler Gateway Timeout und onTimeoutRead für die spezifische API-Proxy-Anfrage finden zu dieser Zeit zu laden, wird eine Zeitüberschreitung beim Message Processor angezeigt.

Beispiel für ein Message Processor-Log mit einem Fehler bei der Gateway-Zeitüberschreitung

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

Im obigen Message Processor-Protokoll sehen Sie, dass der Back-End-Server mit der IP-Adresse Adresse XX.XX.XX.XX hat auch nach 55 Sekunden nicht geantwortet (lastIO=55000ms). Infolgedessen kam es beim Message Processor zu einer Zeitüberschreitung und hat 504 Gateway Timeout Fehler gesendet.

Überprüfen Sie Folgendes: Wie wird das Zeitlimit im Message Processor gesteuert?

Wie wird das Zeitlimit im Message Processor gesteuert? Message Processor mit einem standardmäßigen Zeitüberschreitungswert von 55 Sekunden über die Property HTTPTransport.io.timeout.millis Dieser Wert für die Zeitüberschreitung ist gelten für alle API-Proxys, die zu einer Organisation gehören, die von diesem Message Processor.
- Wenn der Backend-Server nicht innerhalb von 55 Sekunden antwortet, wird die Meldung Der Prozessor überschreitet das Zeitlimit und sendet den Fehler 504 Gateway Timeout an den Client.
Der im Message Processor angegebene Zeitüberschreitungswert kann von der Eigenschaft io.timeout.millis überschrieben. der im API-Proxy angegeben ist. Dieser Zeitlimitwert gilt für eine bestimmte API Proxy, in dem die oben genannte Eigenschaft angegeben ist. Wenn zum Beispiel der Parameter io.timeout.millis wird im API-Proxy auf 10 Sekunden eingestellt, dann Für diesen API-Proxy wird das Zeitlimit von 10 Sekunden verwendet.
- Wenn der Back-End-Server nicht innerhalb von 10 Sekunden für den API-Proxy enthält, überschreitet der Message Processor das Zeitlimit und sendet 504 Gateway Timeout Fehler an den Client.

Auflösung

Prüfen Sie, warum der Backend-Server mehr als 55 Sekunden benötigt, und versuchen Sie, korrigiert/optimiert, um schneller zu reagieren.
Wenn der Backend-Server nicht korrigiert/optimiert werden kann oder bekannt ist, dass das Backend länger als das konfigurierte Zeitlimit benötigt, dann Erhöhen Sie den Wert für das Zeitlimit auf dem Router und dem Message Processor auf einen geeigneten Wert.

Szenario 2. Das Zeitlimit des Routers wird überschritten, bevor der Nachrichtenprozessor/Back-End-Server antwortet.

Sie erhalten möglicherweise 504 Gateway Timeout-Fehler, wenn das Zeitlimit des Routers vor der Meldung Prozessor/Back-End-Server antwortet. Das kann unter folgenden Umständen passieren:

Der auf dem Router eingestellte Wert für das Zeitlimit ist kürzer als der in der Nachricht festgelegte Wert für das Zeitlimit Prozessor. Nehmen wir zum Beispiel an, das Zeitlimit auf dem Router beträgt 50 Sekunden, während die Meldung Prozessor: 55 Sekunden.

Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor
50 Sekunden	55 Sekunden

Der Zeitlimitwert im Message Processor wird mit einem höheren Zeitlimitwert überschrieben: Das Attribut io.timeout.millis, das in der Konfiguration des Zielendpunkts festgelegt ist des API-Proxys:

Beispiel: Folgende Zeitüberschreitungswerte sind festgelegt:

Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor	Zeitüberschreitung innerhalb des API-Proxys
57 Sekunden	55 Sekunden	120 Sekunden

Aber io.timeout.millis ist im API-Proxy auf 120 Sekunden festgelegt:

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

Dann schaltet der Message Processor nach 55 Sekunden keine Zeitüberschreitung, obwohl es eine Zeitüberschreitung ist. (55 Sekunden) ist kleiner als der Wert für das Zeitlimit des Routers (57 Sekunden). Das liegt daran, wird der Timeout-Wert von 55 Sekunden im Message Processor überschrieben durch den Wert von 120 Sekunden, die im API-Proxy festgelegt werden. Der Timeout-Wert des Message Processor für diesen spezifischen API-Proxy bei 120 Sekunden.

Da der Router einen niedrigeren Wert für das Zeitlimit (57 Sekunden) hat als 120 Sekunden, die innerhalb API Proxy deaktiviert, tritt beim Router eine Zeitüberschreitung auf, wenn der Backend-Server nach 57 Tagen nicht antwortet Sekunden.

Diagnose

NGINX-Zugriffsprotokoll prüfen (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Wenn beim Router vor dem Message Processor eine Zeitüberschreitung auftritt, wird der Status 504 angezeigt. in den NGINX-Zugriffslogs für die jeweilige API-Anfrage und den message id von wird der Message Processor als - festgelegt. Das liegt daran, dass der Router keine Antwort erhalten hat. vom Message Processor innerhalb des auf dem Router festgelegten Zeitlimits gesendet.

Beispiel für einen NGINX-Logeintrag, der den Fehler 504 aufgrund einer Zeitüberschreitung des Routers anzeigt
Beachten Sie im obigen Beispiel den Status 504 auf NGINX, die Nachrichten-ID aus der Nachricht Der Prozessor ist - und die verstrichene Zeit beträgt 57,001 Sekunden. Das liegt daran, dass beim Router eine Zeitüberschreitung aufgetreten ist. nach 57,001 Sekunden und wir haben keine Antwort vom Message Processor erhalten.

In diesem Fall werden Broken Pipe Ausnahmen in der Nachricht angezeigt Prozessorlogs (/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>

Dieser Fehler wird angezeigt, da der Router bei einer Zeitüberschreitung die Verbindung mit der Message Processor. Wenn der Message Processor die Verarbeitung abgeschlossen hat, versucht er, den an den Router sendet. Da die Verbindung zum Router bereits unterbrochen ist, erhalten Sie den Broken Pipe exception für den Message Processor.

Diese Ausnahme ist unter den oben genannten Umständen zu erwarten. Die tatsächlichen Der Grund für den Fehler 504 Gateway Timeout ist, dass der Backend-Server immer noch länger braucht, um zu antworten. und Sie müssen dieses Problem angehen.

Auflösung

Bei einem benutzerdefinierten Backend-Server <ph type="x-smartling-placeholder">

Prüfen Sie, warum der Backend-Server so lange zum Antworten braucht, und versuchen Sie, korrigiert/optimiert, um schneller zu reagieren.

Wenn es nicht möglich ist, den Backend-Server zu reparieren/optimieren, oder wenn bekannt ist, dass der lange Zeit in Anspruch nimmt, dann Erhöhen Sie den Timeout-Wert Router und Message Processor.

Idee: Legen Sie den Wert für das Zeitlimit für die verschiedenen Komponenten im Auftrag:

Zeitüberschreitung auf dem Client > Zeitlimit auf Router > Zeitüberschreitung bei Nachricht Prozessor > Zeitüberschreitung innerhalb des API-Proxys

Bei einem Node.js-Back-End-Server: <ph type="x-smartling-placeholder">
1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob er lange dauern, bis eine Antwort zurückgegeben wird. Prüfen Sie, warum die Back-End-Server länger brauchen und beheben Sie das Problem entsprechend.
2. Überprüfen Sie, ob bei den Message Processorn eine hohe CPU- oder Arbeitsspeichernutzung auftritt: <ph type="x-smartling-placeholder">
  1. Wenn die CPU-Auslastung bei einem Message Processor hoch ist, generieren Sie drei Thread Dumps alle 30 Sekunden mit dem folgenden Befehl:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Wenn bei einem Message Processor eine hohe Speicherauslastung auftritt, generieren Sie einen Heap Dump mit dem folgenden Befehl:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Das sollte die CPU aus und Arbeitsspeicher:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Überwachen Sie die API-Aufrufe, um festzustellen, ob das Problem weiterhin besteht.
  5. Wenden Sie sich an den Apigee Edge-Support und geben Sie Folgendes an: Thread-Dumps, Heap-Dump und Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) die Ursache für eine hohe CPU-/Arbeitsspeicherauslastung.

Prüfen: Wie wird das Zeitlimit für NodeJS-Backend-Server in der Nachricht gesteuert? Prozessor

Der NodeJS-Back-End-Server wird innerhalb des JVM-Prozesses des Message Processor ausgeführt. Die Der Zeitüberschreitungswert für NodeJS-Backend-Server wird über das Attribut gesteuert http.request.timeout.seconds in der Datei nodejs.properties. Dieses ist standardmäßig auf 0 gesetzt, d. h. das Zeitlimit ist standardmäßig für alle API-Proxys, die zu einer Organisation gehören, die von diesem Message Processor bedient wird. Selbst wenn Node.js-Back-End-Server lange braucht, tritt beim Message Processor keine Zeitüberschreitung auf.
Wenn der Node.js-Back-End-Server lange dauert und die API Anfrage ist > 57 Sekunden, dann tritt das Zeitlimit für den Router auf und sendet 504 Gateway Timeout Fehler an den Client.

Szenario 3 – Zeitlimit der Clientanwendung vor dem Router/Nachrichtenprozessor/Back-End-Server antwortet

Sie erhalten möglicherweise 504 Gateway Timeout-Fehler, wenn das Zeitlimit der Clientanwendung vor dem der Back-End-Server antwortet. Diese Situation kann in folgenden Fällen eintreten:

Der in der Clientanwendung festgelegte Zeitüberschreitungswert ist niedriger als der in der Router und Message Processor:

Beispiel: Folgende Zeitüberschreitungswerte sind festgelegt:

Zeitüberschreitung auf dem Client	Zeitüberschreitung auf dem Router	Zeitüberschreitung beim Message Processor
50 Sekunden	57 Sekunden	55 Sekunden

In diesem Fall die Gesamtzeit, die verfügbar ist, um eine Antwort auf eine API-Anfrage über Edge zu erhalten ist <= 50 Sekunden. Dazu gehört auch die zum Stellen einer API-Anfrage benötigte Zeit, von Edge (Router, Message Processor) verarbeitet, wobei die Anfrage an den Backend-Server gesendet wird (falls zutreffend), Backend-Verarbeitung der Anfrage und Senden der Antwort, Edge-Verarbeitung und schließlich zurück an den Client senden.

Wenn der Router dem Client nicht innerhalb von 50 Sekunden antwortet, und die Verbindung mit dem Router trennen. Der Client erhält den Antwortcode: 504

Dies führt dazu, dass NGINX den Statuscode 499 festlegt, um anzugeben, dass der Client die

Diagnose

Wenn bei der Client-Anwendung eine Zeitüberschreitung auftritt, bevor sie eine Antwort vom Router erhält, trenne die Verbindung zum Router. In diesem Fall wird der Statuscode 499 in die NGINX-Zugriffsprotokolle für die jeweilige API-Anfrage.
NGINX-Logeintrag mit Statuscode 499
Beachten Sie im obigen Beispiel, dass der Status von 499 auf der NGINX und die verstrichene Gesamtzeit 50,001 Sekunden. Dies bedeutet, dass beim Client nach 50,001 Sekunden eine Zeitüberschreitung aufgetreten ist.

In diesem Fall werden Broken Pipe Ausnahmen in der Nachricht angezeigt Prozessorlogs (/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>

Nach einer Zeitüberschreitung des Routers wird die Verbindung mit dem Message Processor geschlossen. Wenn der Parameter Der Message Processor schließt die Verarbeitung ab und versucht, die Antwort an den Router zu schreiben. Da die Verbindung zum Router bereits geschlossen ist, erhalten Sie das Broken Pipe exception auf dem Message Processor.
Diese Ausnahme ist unter den oben beschriebenen Umständen zu erwarten. Die eigentliche Ursache für Der Fehler 504 Gateway Timeout besagt, dass die Antwort des Back-End-Servers lange dauert und müssen Sie dieses Problem angehen.

Auflösung

Wenn es sich um Ihren benutzerdefinierten Backend-Server handelt, gehen Sie so vor: <ph type="x-smartling-placeholder">

Überprüfen Sie den Back-End-Server, um festzustellen, warum es länger als 57 Sekunden dauert, und prüfen Sie, Es kann korrigiert/optimiert werden, um schneller zu reagieren.

Wenn es nicht möglich ist, den Backend-Server zu reparieren/optimieren, oder wenn Sie wissen, lange Zeit in Anspruch nimmt, erhöhen Sie dann den Router und Message Processor.

Idee: Legen Sie den Zeitüberschreitungswert für die verschiedenen Komponenten im Auftrag:

Zeitüberschreitung auf dem Client > Zeitlimit auf Router > Zeitüberschreitung bei Nachricht Prozessor > Zeitüberschreitung innerhalb des API-Proxys

Bei einem NodeJS-Back-End: <ph type="x-smartling-placeholder">
1. Prüfen Sie, ob der NodeJS-Code Aufrufe an andere Back-End-Server sendet und ob dieser wenn es lange dauert, bis sie zurückgegeben werden. Prüfen Sie, warum diese Backend-Server länger benötigen.
2. Überprüfen Sie, ob bei den Message Processors eine hohe CPU- oder Arbeitsspeichernutzung auftritt: <ph type="x-smartling-placeholder">
  1. Wenn bei einem Message Processor eine hohe CPU-Auslastung auftritt, generieren Sie drei Thread Dumps alle 30 Sekunden mit dem folgenden Befehl:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Wenn bei einem Message Processor eine hohe Speicherauslastung auftritt, generieren Sie einen Heap-Dump mit dem folgenden Befehl:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollten die CPU und Arbeitsspeicher:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Überwachen Sie die API-Aufrufe, um festzustellen, ob das Problem weiterhin besteht.
  5. Wenden Sie sich an den Apigee Edge-Support und geben Sie Folgendes an: Thread-Dumps, Heap-Dump und Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)damit sie die Ursache für eine hohe CPU-/Arbeitsspeicherauslastung.

Erhöhen Sie den Wert für das Zeitlimit auf Router und Message Processor

Wählen Sie die Zeitüberschreitungswerte, die auf dem Router und dem Message Processor festgelegt werden sollen, mit Bedacht aus. Ihren Anforderungen entsprechen. Legen Sie keine beliebig großen Zeitüberschreitungswerte fest. Wenn du Hilfe benötigst, wende dich an Apigee Edge-Unterstützung

Router

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

Erstellen Sie die Datei /opt/apigee/customer/application/router.properties im Routermaschine, falls noch nicht vorhanden.
Fügen Sie dieser Datei die folgende Zeile hinzu:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
```
Wenn Sie beispielsweise einen Wert für das Zeitlimit von 120 Sekunden festlegen möchten, legen Sie ihn wie folgt fest: folgt:
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
```
Achten Sie darauf, dass diese Datei Apigee gehört:

Starten Sie den Router neu:

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

Wenn Sie mehr als einen Router haben, wiederholen Sie die oben beschriebenen Schritte auf allen Routern.

Message Processor

/opt/apigee/customer/application/message-processor.properties-Datei erstellen am den Message Processor-Computer, falls er noch nicht vorhanden ist.
Fügen Sie dieser Datei die folgende Zeile hinzu:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Wenn Sie beispielsweise einen Wert für das Zeitlimit von 120 Sekunden festlegen möchten, legen Sie ihn wie folgt fest: folgt:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Achten Sie darauf, dass diese Datei Apigee gehört:

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

Starten Sie den Message Processor neu:

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

Wenn Sie mehr als einen Message Processor haben, wiederholen Sie die obigen Schritte für alle Prozessoren.

Idee: Lege den Timeout-Wert für die verschiedenen Komponenten in der folgenden Reihenfolge fest:

Zeitüberschreitung auf dem Client > Zeitlimit auf Router > Zeitüberschreitung beim Message Processor > Zeitüberschreitung innerhalb des API-Proxys

Langsame API-Anfrageverarbeitung durch Edge

Wenn Edge sehr langsam ist und/oder die Verarbeitung der API-Anfrage lange dauert, erhalten Sie eine 504 Gateway Timeout Fehler.

Diagnose

Verzeichnen Sie die betroffene API in der Edge-Benutzeroberfläche.
Warten Sie entweder, bis der Fehler auftritt, oder führen Sie, wenn Sie den API-Aufruf haben, einige API-Aufrufe aus und reproduzieren Sie den Fehler 504 Gateway Timeout.
Hinweis: In diesem Fall wird möglicherweise eine erfolgreiche Antwort in der Trace-Datei angezeigt.
1. Beim Router/Client tritt eine Zeitüberschreitung auf, da der Message Processor nicht innerhalb der Zeitlimit auf dem Router/Client angegeben werden (je nachdem, welcher Zeitraum am kürzesten ist). Der Message Processor verarbeitet die Anfrage jedoch weiter und erfolgreich war.
2. Darüber hinaus wird der Wert HTTPTransport.io.timeout.millis, der auf der Message Processor wird nur ausgelöst, wenn der Message Processor mit einem HTTP/HTTPS kommuniziert Back-End-Server. Das Zeitlimit wird also nicht ausgelöst, wenn eine Richtlinie (andere als ServiceCallout-Richtlinie) im API-Proxy sehr lange dauert.
Prüfen Sie nach dem Auftreten des Fehlers die spezifische Anfrage mit der längsten verstrichene Zeit.
Überprüfen Sie die verstrichene Zeit in jeder Phase und notieren Sie sich die Phase mit der längsten Zeit. ausgegeben haben.
Bei der längsten verstrichenen Zeit in einer der Richtlinien außer dem Dienst Callout-Richtlinie enthält, weist dies darauf hin, dass die Verarbeitung des
Hier ist ein Beispiel für ein UI-Trace, das eine sehr lange verstrichene Zeit für die JavaScript-Richtlinie zeigt:
Im obigen Beispiel stellen Sie fest, dass die JavaScript-Richtlinie ungewöhnlich lange etwa 245 Sekunden.

Auflösung

Prüfen Sie, ob die Richtlinie, deren Antwort lange gedauert hat, und benutzerdefinierten Code enthält, der zeitaufwändig in der Verarbeitung sein. Wenn es einen solchen Code gibt, den erkannten Code korrigieren/optimieren.
Wenn kein benutzerdefinierter Code vorhanden ist, der eine lange Verarbeitungszeit verursachen könnte, prüfen Sie, ob die Meldung Bei Prozessoren ist die CPU- oder Arbeitsspeichernutzung hoch: <ph type="x-smartling-placeholder">
1. Wenn die CPU-Auslastung bei einem Message Processor hoch ist, generieren Sie drei Thread Dumps alle 30 Sekunden mit dem folgenden Befehl:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Wenn ein Nachrichtenprozessor eine hohe Speicherauslastung hat, generieren Sie einen Heap-Dump mit dem folgenden Befehl:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Starten Sie den Message Processor mit dem folgenden Befehl neu. Dadurch sollte sich die CPU-Auslastung und „Informationen merken“.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Überwachen Sie die API-Aufrufe und prüfen Sie, ob das Problem weiterhin besteht.
5. Wenden Sie sich an den Apigee Edge-Support und geben Sie den Thread an. Dumps, Heap-Dump und Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)damit sie die Ursache für eine hohe CPU-/Arbeitsspeicherauslastung.

Probleme mithilfe von API-Monitoring diagnostizieren

Mit der API-Überwachung können Sie Problembereiche schnell isolieren, um Fehler-, Leistungs- und Latenzprobleme sowie deren Ursache zu diagnostizieren. wie z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

Schritt durch ein Beispielszenario, das zeigt, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API-Monitoring beheben. Beispielsweise können Sie eine Warnung einrichten, die informiert wird, wenn die Anzahl der 504-Statuscodes einen bestimmten Schwellenwert überschreitet.