Freigeben über

Behandeln von Leistungsproblemen in API-Aufrufen

  • Artikel

Im Blog zur Azure API Management-Problembehandlungsreihe ist dies das vierte Szenario des Labs. Stellen Sie sicher, dass Sie die Anweisungen zum Einrichten des Labs wie folgt befolgt haben, um das Problem neu zu erstellen.

Ursprüngliche Produktversion: API Management Service
Ursprüngliche KB-Nummer: 4464929

Problembeschreibung

Der API-ProductStore in APIM kommuniziert mit dem Back-End-Endpunkt (https://productstoreapp.azurewebsites.net), um Datensätze bei Bedarf einfach zu erstellen, zu lesen, zu aktualisieren und zu löschen. Beim Aufrufen der unten aufgeführten API-Vorgänge können jedoch einige Leistungsprobleme und Ausnahmen auftreten. Um das Testen zu vereinfachen, behalten Sie nur drei Produkte mit IDs zwischen 1 und 3 bei.

  • Eine der API-Funktionen Products_GetAllProducts benötigt 5 Sekunden, um die Ergebnisse zurückzugeben, während die erwartete Antwortzeit weniger als eine Sekunde beträgt.

  • Beim Löschen eines Produkts mit einer der oben genannten IDs (1 bis 3) erhalten Sie http 500 – Interner Serverfehler mit der folgenden Meldung, indem Sie Products_DeleteProduct Vorgang aufrufen.

    {
    "Message": "Ein Fehler ist aufgetreten."
    }

  • Products_PutProduct Vorgang, der ein Produkt aktualisiert, wird unerwartet gedrosselt, sodass HTTP 429 – Zu viele Anforderungen mit der folgenden Fehlermeldung ausgelöst werden, unabhängig von der Produkt-ID und dem Anforderungstext, die Sie in der Anforderung senden. Wenn der Kunde beispielsweise den Produktpreis von "Tomato Soup" mit der Produkt-ID = 1 mit dem folgenden JSON-Text aktualisiert, erhält er HTTP 429 status Code.

    Id des Vorlagenparameters: 1
       Anforderungstext: {"Name": "Tomatensuppe","Kategorie": "Lebensmittel","Preis": 2.45}
       Antworttext:
    {
    Das Ratenlimit wird überschritten. Versuchen Sie es nach einiger Zeit erneut.
    }

Schritte zur Problembehandlung

  • Bei der Behandlung von Leistungsproblemen ist die beste Methode zur Fehlerisolation die Erfassung der [APIM-Inspektor-Ablaufverfolgung, die die in jedem Abschnitt benötigte Zeit anzeigt (Eingehend/Back-End/Ausgehend).

  • Wenn Sie die API Inspector-Ablaufverfolgung für das erste Problem analysieren, würden Sie feststellen, dass der Back-End-Abschnitt die meiste Zeit (ca. 5 Sekunden) in Anspruch nimmt. Dies bedeutet, dass eine gewisse Langsamkeit oder ein zeitintensiver Vorgang am Back-End stattfindet.

    "source": "forward-request",
    "timestamp": "2018-07-29T16:16:46.6615081Z",
    "elapsed": "00:00:05.5844430","data": {
    "response": {
    "status": {
    "code": 200,
    "reason": "OK"
    }

  • Nachdem Sie isoliert haben, dass die Langsamkeit im Back-End liegt, müssen Sie den Back-End-Anwendungscode der Web-API-Anwendung untersuchen. In Szenarien, in denen Sie keinen Zugriff auf das Back-End haben, können Sie die Zwischenspeicherung auf APIM-Ebene wie unten beschrieben implementieren. Erfahren Sie, wie Sie Cacherichtlinien implementieren können, um die Leistung in Azure API Management zu verbessern.

    <?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>

  • Führen Sie für das zweite Problem (HTTP 500 – Interner Serverfehler) das gleiche Verfahren zur Analyse der APIM-Inspektor-Ablaufverfolgung aus. Http 500 status Code sollte unter dem Antwortsattribut "forward-request" angezeigt werden.

  • Dies bedeutet, dass die Back-End-API HTTP 500 zurückgegeben hat, da im Back-End-Code eine Ausnahme nicht behandelt wurde. Auf APIM-Ebene gibt es kein Problem.

    forward-request (841,060 ms)
    {
    "response": {
    "status": {
    "code": 500,
    "reason": "Interner Serverfehler"
    }

  • Für das dritte Problem (HTTP 429 – Zu viele Anforderungen) sieht es so aus, als ob Sie die Api-Aufrufratenbegrenzung erreichen. Wahrscheinlich können Sie überprüfen, ob auf Vorgangsebene eine Richtlinie für "Ratenbegrenzung" oder "Ratenbegrenzung nach Schlüssel" implementiert ist.

  • Wenn Sie solche Richtlinien auf Vorgangsebene nicht finden können, klicken Sie auf die Schaltfläche Effektive Richtlinie berechnen . Auf dieser Schaltfläche werden alle geerbten Richtlinien von verschiedenen Ebenen angezeigt, z. B. einige Richtlinien auf Produktebene, die dieses Problem verursachen können.

  • Hier sollten Sie feststellen, dass einige Richtlinien auf API-Ebene implementiert sind, die die API-Aufrufrate nicht wirklich einschränken, aber ihre Aktion imitieren, indem eine angepasste Antwort an den Client zurückgegeben wird, indem die Richtlinien "return-response" und "set-status" im ausgehenden Abschnitt verwendet werden.

    <?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>

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.