Freigeben über

Behandeln von Leistungsproblemen in API-Aufrufen

  • Artikel

Dies ist das vierte Szenario des Labors, das sich auf den Blog zu Azure API Management Troubleshooting Series bezieht. Stellen Sie sicher, dass Sie die Anweisungen zum Einrichten des Labors entsprechend befolgt haben, um das Problem neu zu erstellen.

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

Symptome

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. Es können jedoch einige Leistungsprobleme und Ausnahmen auftreten, während Sie die unten aufgeführten API-Vorgänge aufrufen. Um die Tests zu vereinfachen, behalten Sie nur drei Produkte mit IDs zwischen 1 und 3 bei.

  • Eine der API-Funktionen Products_GetAllProducts dauert 5 Sekunden, um die Ergebnisse zurückzugeben, während die erwartete Antwortzeit kleiner als eine Sekunde ist.

  • 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.

    {
    "Nachricht": "Fehler ist aufgetreten."
    }

  • Products_PutProduct Vorgang, der ein Produkt aktualisiert, unerwartet gedrosselt wird, löst HTTP 429 - Zu viele Anforderungen mit der folgenden Fehlermeldung unabhängig von der Produkt-ID und dem Anforderungstext aus, die Sie in der Anforderung senden. Wenn der Kunde z. B. den Produktpreis von "Tomato Soup" aktualisiert, der die Produkt-ID = 1 mit dem folgenden JSON-Textkörper hat, erhält er DEN HTTP 429-Statuscode.

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

Schritte zur Fehlersuche

  • Bei der Problembehandlung bei Leistungsproblemen wird die Fehlerisolationstechnik am besten erfasst [APIM Inspector Trace, die die in den einzelnen Abschnitten benötigte Zeit zeigt (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 dauert (ca. 5 Sekunden), was bedeutet, dass im Back-End einige Langsamkeit oder ein langer Vorgang stattfindet.

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

  • Nachdem Sie isoliert haben, dass sich die Langsamkeit im Back-End befindet, 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 APIM-Ebene wie unten implementieren. Erfahren Sie, wie Sie Zwischenspeicherungsrichtlinien 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) dasselbe Verfahren zur Analyse der APIM-Inspektorablaufverfolgung aus, und wir sollten HTTP 500-Statuscode unter dem Antwortattribute "Forward-request" sehen.

  • Dies bedeutet, dass die Back-End-API HTTP 500 aufgrund einer unbehandelten Ausnahme im Back-End-Code zurückgegeben hat, es gibt kein Problem auf APIM-Ebene.

    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 das API-Aufrufratenlimit erreicht haben. Wahrscheinlich können Sie überprüfen, ob eine "Rate-Limit"- oder "Rate-limit-by-Key"-Richtlinie auf Betriebsebene implementiert ist.

  • Wenn Sie solche Richtlinien auf Betriebsebene nicht finden können, klicken Sie auf die Schaltfläche "Effektive Richtlinie berechnen", die alle geerbten Richtlinien aus verschiedenen Ebenen anzeigt, z. B. einige Richtlinien auf Produktebene, die dieses Problem verursachen können.

  • Hier sollten Sie feststellen, dass einige Richtlinien auf API-Ebene implementiert werden, die die API-Aufrufrate nicht wirklich einschränken, sondern ihre Aktion imitieren, indem sie eine angepasste Antwort zurück an den Client mithilfe von "Return-Response"- und "Set-Status"-Richtlinien im ausgehenden Abschnitt zurückgibt.

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