Dela via

Felsöka prestandaproblem i API-anrop

  • Artikel

Med hjälp av bloggen om felsökningsserien för Azure API Management är det här det fjärde scenariot i labbet. Se till att du har följt instruktionerna för labbkonfigurationen enligt detta för att återskapa problemet.

Ursprunglig produktversion: API Management Service
Ursprungligt KB-nummer: 4464929

Symptom

API ProductStore i APIM kommunicerar med serverdelsslutpunkten (https://productstoreapp.azurewebsites.net) för att enkelt skapa, läsa, uppdatera och ta bort poster vid behov. Du kan dock stöta på vissa prestandaproblem och undantag när du anropar DE API-åtgärder som anges nedan. För att underlätta testningen bör du bara behålla tre produkter med ID:t från 1 till 3.

  • En av API-funktionerna Products_GetAllProducts tar 5 sekunder att returnera resultatet, medan den förväntade svarstiden är mindre än en sekund.

  • När du tar bort en produkt som har något av ovan nämnda ID:t (1 till 3) får du HTTP 500 – internt serverfel med meddelandet nedan genom att anropa Products_DeleteProduct åtgärd.

    {
    "Meddelande": "Ett fel har inträffat."
    }

  • Products_PutProduct åtgärd som uppdaterar en produkt begränsas oväntat och genererar HTTP 429 – För många begäranden med felmeddelandet nedan oavsett produkt-ID och begärandetext som du skickar i begäran. Om kunden till exempel uppdaterar produktpriset för "Tomato Soup" med produkt-ID = 1 med Json-brödtexten nedan får han HTTP 429-statuskod.

    Mallparameter-ID: 1
       Begärandetext: {"Namn": "Tomatsoppa","Kategori": "Livsmedel","Pris": 2.45}
       Svarstext:
    {
    Hastighetsbegränsning överskriden. Försök igen efter en stund.
    }

Felsökningsanvisningar

  • När du felsöker prestandaproblem är den bästa metoden för felisolering att samla in [APIM-kontrollspårning som visar hur mycket tid det tar i varje avsnitt (inkommande/serverdel/utgående).

  • Om du analyserar API Inspector-spårningen för det första problemet skulle du märka att serverdelsavsnittet tar större delen av tiden (cirka 5 sekunder), vilket innebär att det sker en viss långsam eller tidskrävande åtgärd på serverdelen.

    "source": "forward-request",
    "tidsstämpel": "2018-07-29T16:16:46.6615081Z",
    "förflutit": "00:00:05.5844430","data": {
    "response": {
    "status": {
    "code": 200,
    "reason": "OK"
    }

  • När du har isolerat att långsamheten är på serverdelen måste du undersöka serverdelsprogrammets kod för webb-API-programmet. För scenarier där du inte har åtkomst till serverdelen kan du implementera cachelagring på APIM-nivå som nedan. Läs mer om hur du kan implementera cachelagringsprinciper för att förbättra prestanda i Azure API Management.

    <?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ör det andra problemet (HTTP 500 – internt serverfel) följer du samma procedur för att analysera APIM-kontrollspårningen och vi bör se HTTP 500-statuskoden under svarsattributet "vidarebefordra begäran".

  • Det innebär att serverdels-API:et returnerade HTTP 500 på grund av ett ohanterat undantag vid serverdelskoden. Det finns inget problem på APIM-nivå.

    forward-request (841.060 ms)
    {
    "response": {
    "status": {
    "code": 500,
    "reason": "Internal Server Error"
    }

  • För det tredje problemet (HTTP 429 – För många begäranden) ser det ut som om du når GRÄNSEN för API-anropsfrekvens. Förmodligen kan du kontrollera om det finns någon "rate-limit" eller "rate-limit-by-key"-princip implementerad på åtgärdsnivå.

  • Om du inte hittar några sådana principer på åtgärdsnivå klickar du på knappen Beräkna effektiv princip , som visar alla ärvda principer från olika nivåer, som om du har vissa principer på produktnivå som kan orsaka det här problemet.

  • Här bör du observera att vissa principer implementeras på API-nivå som inte riktigt begränsar API-anropsfrekvensen men efterliknar dess åtgärd genom att returnera ett anpassat svar tillbaka till klienten med hjälp av principer för "return-response" och "set-status" vid utgående avsnitt.

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

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.