Beheben von Leistungsproblemen in Azure API Management bei API-Aufrufen

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie Azure API Management Leistungsprobleme bei API-Aufrufen behandeln, einschließlich Back-End-Latenz und HTTP 500- und 429-Fehler. Verwenden Sie diese Schritte, um Fehler zu isolieren und API-Reaktionszeiten zu verbessern.

Dieser Artikel ist das vierte Szenario des Azure API Management Problembehandlungs-Reihenlabors. Stellen Sie sicher, dass Sie die Anweisungen zum Einrichten des Labs gemäß den Lab-Anweisungen der Reihe zur Problembehandlung für API Management befolgen.

Ursprüngliche Produktversion: API-Verwaltungsdienst
Ursprüngliche KB-Nummer: 4464929

Symptome

Der API-ProductStore in der API-Verwaltung kommuniziert mit dem Back-End-Endpunkt (https://productstoreapp.azurewebsites.net) zum Erstellen, Lesen, Aktualisieren und Löschen von Datensätzen nach Bedarf. Es können jedoch Leistungsprobleme und Ausnahmen auftreten, wenn Sie die folgenden API-Vorgänge ausführen.

• Products_GetAllProducts dauert fünf Sekunden, um Ergebnisse zurückzugeben, die erwartete Antwortzeit ist jedoch weniger als eine Sekunde.

• Wenn Sie den Products_DeleteProduct Vorgang verwenden, um ein Produkt mit einer der zuvor erwähnten IDs (eins bis drei) zu löschen, erhalten Sie einen HTTP 500 - Interner Serverfehler mit der folgenden Meldung:

  "Nachricht": "Fehler ist aufgetreten."

• Ein Vorgang, der ein Produkt aktualisiert, wird unerwartet gedrosselt und führt zum Fehler HTTP 429 - Zu viele Anfragen. Dieser Fehler tritt unabhängig von der Produkt-ID und dem Anforderungstext auf. Wenn der Kunde beispielsweise den Produktpreis von „Tomatensuppe“ für die Produkt-ID 1 mithilfe des folgenden Beispiels aktualisiert, erhält er den HTTP-Statuscode 429.

  Vorlagenparameter-ID: 1
     Anforderungstext: {"Name": "Tomatensuppe","Kategorie": "Lebensmittel","Preis": 2.45}
     Antworttext:
  {
  Das Ratenlimit wurde überschritten. Versuchen Sie es später noch einmal.
  }

Troubleshooting

Bei der Problembehandlung von Leistungsproblemen besteht die beste Methode, Fehler zu isolieren, darin, eine API Management-Inspektor-Ablaufverfolgung zu erfassen, aus der die für die einzelnen Abschnitte benötigte Zeit hervorgeht (Inbound, Backend und Outbound).

Products_GetAllProducts Latenz

Wenn Sie die API Inspector-Ablaufverfolgung für dieses Problem analysieren, sehen Sie, dass das Back-End die meiste Zeit benötigt (ungefähr fünf Sekunden). Dieses Ergebnis bedeutet, dass es im Backend zu einer gewissen Verlangsamung kommt oder ein lang laufender Vorgang ausgeführt wird. Das folgende Beispiel zeigt die Back-End-Antwortzeit in der API Inspector-Ablaufverfolgung:

"source": "weiterleitungsanfrage"
"Timestamp": "2018-07-29T16:16:46.6615081Z",
"verstrichene Zeit": "00:00:05.5844430",
"data": {
"response": {
"status": {
"code": 200,
"reason": "OK" }

Nachdem Sie isoliert haben, dass die Langsamkeit im Back-End erfolgt, müssen Sie den Back-End-Anwendungscode der Web-API-Anwendung untersuchen. Für Szenarien, in denen Sie keinen Zugriff auf das Back-End haben, können Sie die Zwischenspeicherung auf API-Verwaltungsebene implementieren, wie im folgenden Beispiel gezeigt.

    <?xml version="1.0" encoding="UTF-8"?>
    <policies>
       <inbound>
          <base />
          <cache-lookup vary-by-developer="true" vary-by-developer-groups="true" must-revalidate="true" downstream-caching-type="public" />
       </inbound>
       <backend>
          <base />
       </backend>
       <outbound>
          <base />
          <cache-store duration="60" />
       </outbound>
       <on-error>
          <base />
       </on-error>
    </policies>

Weitere Informationen zum Zwischenspeichern finden Sie unter "Zwischenspeichern hinzufügen", um die Leistung in Azure API Management zu verbessern.

Products_DeleteProduct HTTP 500 interner Serverfehler

Führen Sie für dieses Problem dasselbe Verfahren zum Analysieren der API-Verwaltungsinspektorablaufverfolgung aus. Wahrscheinlich wird unter dem forward-request Antwort-Attribut ein HTTP 500-Statuscode angezeigt.

Dieser Statuscode bedeutet, dass die Back-End-API HTTP 500 aufgrund einer unbehandelten Ausnahme im Back-End-Code zurückgibt. Es gibt kein Problem auf der API-Verwaltungsebene, wie im folgenden Beispiel gezeigt:

Weiterleitungsanfrage (841,060 ms)
{
"response": {
"status": {
"code": 500,
"Reason": "Interner Serverfehler"
}

Products_PutProduct HTTP 429 Fehler: zu viele Anfragen

Bei diesem Problem scheint es so zu sein, als ob Sie eine API-Aufrufratengrenze erreicht haben. Überprüfen Sie, ob auf der Betriebsebene eine rate-limit- oder rate-limit-by-key-Richtlinie implementiert ist.

Wenn Sie keine Richtlinien wie diese auf Vorgangsebene finden können, wählen Sie " Effektive Richtlinie berechnen" aus. Diese Aktion zeigt alle geerbten Richtlinien aus verschiedenen Ebenen an, einschließlich Richtlinien auf Produktebene, die dieses Problem verursachen können.

Möglicherweise werden einige Richtlinien auf API-Ebene implementiert, die die API-Aufrufrate nicht einschränken. Stattdessen ahmt sie dessen Verhalten nach, indem sie unter Verwendung der Richtlinien return-response und für den Abschnitt set-status eine benutzerdefinierte Antwort an den Client zurückgibt, wie im folgenden Beispiel gezeigt:

    <?xml version="1.0" encoding="UTF-8"?>
    <outbound>
       <!--base: Begin Api scope-->
       <return-response>
          <set-status code="429" reason="Too many requests" />
          <set-body><![CDATA[{

    Rate limit is exceeded. Try again after some time.

    }]]></set-body>
       </return-response>
       <!--base: End Api scope-->
    </outbound>