Delen via

Prestatieproblemen in API-aanroepen oplossen

  • Artikel

Dit is het vierde scenario van het lab, wat verwijst naar de blog over azure API Management Troubleshooting Series. Zorg ervoor dat u de instructies voor het instellen van het lab hebt gevolgd om het probleem opnieuw te maken.

Oorspronkelijke productversie: API Management Service
Oorspronkelijk KB-nummer: 4464929

Symptomen

De API ProductStore in APIM communiceert met het back-endeindpunt (https://productstoreapp.azurewebsites.net) om records eenvoudig te maken, lezen, bijwerken en verwijderen wanneer dat nodig is. U kunt echter prestatieproblemen en uitzonderingen ondervinden tijdens het aanroepen van de API-bewerkingen die hieronder worden vermeld. Houd voor een gemakkelijke test slechts drie producten met id's variërend van 1 tot 3.

  • Een van de API-functies Products_GetAllProducts duurt vijf seconden om de resultaten te retourneren, terwijl de verwachte reactietijd minder dan een seconde is.

  • Tijdens het verwijderen van een product met een van de bovenstaande genoemde id's (1 tot 3), krijgt u HTTP 500 - Interne serverfout met het onderstaande bericht door Products_DeleteProduct bewerking aan te roepen.

    {
    "Bericht": "Er is een fout opgetreden."
    }

  • Products_PutProduct bewerking die een product bijwerkt onverwacht wordt beperkt, wordt HTTP 429 - Te veel aanvragen gegenereerd met het onderstaande foutbericht, ongeacht product-id en aanvraagbody, die u in de aanvraag verzendt. Als de klant bijvoorbeeld de productprijs van 'Tomaatsoep' bijwerkt met product-id = 1 met de onderstaande Json-body, krijgt hij HTTP 429-statuscode.

    Sjabloonparameter-id: 1
       Aanvraagtekst: {"Naam": "Tomatensoep","Categorie": "Boodschappen","Prijs": 2,45}
       Hoofdtekst van antwoord:
    {
    De limiet wordt overschreden. Probeer het na enige tijd opnieuw.
    }

Stappen voor probleemoplossing

  • Tijdens het oplossen van prestatieproblemen is de beste manier om foutisolatietechniek vast te leggen [APIM Inspector-tracering die de tijd toont die in elke sectie is genomen (inkomend/back-end/uitgaand).

  • Als u de API Inspector-tracering analyseert voor het eerste probleem, merkt u dat de back-endsectie de meeste tijd in beslag neemt (ongeveer 5 seconden), wat betekent dat er enige traagheid of langdurige bewerking plaatsvindt in de back-end.

    "source": "forward-request",
    "tijdstempel": "2018-07-29T16:16:46.6615081Z",
    "verstreken": "00:00:05.5844430","data": {
    "antwoord": {
    "status": {
    "code": 200,
    "reden": "OK"
    }

  • Zodra u hebt geïsoleerd dat de traagheid zich in de back-end bevindt, moet u de code van de back-endtoepassing van de web-API-toepassing onderzoeken. Voor scenario's waarin u geen toegang hebt tot de back-end, kunt u caching implementeren op APIM-niveau, zoals hieronder. Lees hoe u cachebeleid kunt implementeren om de prestaties in Azure API Management te verbeteren.

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

  • Voor het tweede probleem (HTTP 500 - Interne serverfout) volgt u dezelfde procedure voor het analyseren van de APIM-controletracering. We moeten http 500-statuscode zien onder het antwoordkenmerk 'forward-request'.

  • Dit betekent dat de back-end-API HTTP 500 heeft geretourneerd omdat er een niet-verwerkte uitzondering is opgetreden in de back-endcode, er geen probleem is op APIM-niveau.

    forward-request (841.060 ms)
    {
    "antwoord": {
    "status": {
    "code": 500,
    "reason": "Interne serverfout"
    }

  • Voor het derde probleem (HTTP 429 - Te veel aanvragen) lijkt het erop dat u de frequentielimiet voor API-aanroepen bereikt. Waarschijnlijk kunt u controleren of er beleid 'rate-limit' of 'rate-limit-by-key' is geïmplementeerd op bewerkingsniveau.

  • Als u dergelijke beleidsregels niet kunt vinden op bewerkingsniveau, klikt u op de knop Effectief beleid berekenen, waarin alle overgenomen beleidsregels van verschillende niveaus worden weergegeven, zoals u mogelijk een aantal beleidsregels op productniveau hebt die dit probleem kunnen veroorzaken.

  • Hier ziet u dat sommige beleidsregels zijn geïmplementeerd op API-niveau die de frequentie van de API-aanroep niet echt beperken, maar de actie nabootsen door een aangepast antwoord terug te sturen naar de client met behulp van beleid 'return-response' en 'set-status' in de uitgaande sectie.

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

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.