Udostępnij za pośrednictwem

Rozwiązywanie problemów z wydajnością wywołań interfejsu API

  • Artykuł

Korzystając z bloga z serii rozwiązywania problemów z usługą Azure API Management, jest to czwarty scenariusz laboratorium. Upewnij się, że wykonano instrukcje konfiguracji laboratorium zgodnie z tym, aby ponownie utworzyć problem.

Oryginalna wersja produktu: usługa API Management
Oryginalny numer KB: 4464929

Symptomy

Magazyn produktów interfejsu API w usłudze APIM komunikuje się z punktem końcowym zaplecza (https://productstoreapp.azurewebsites.net), aby łatwo tworzyć, odczytywać, aktualizować i usuwać rekordy zgodnie z potrzebami. Jednak podczas wywoływania operacji interfejsu API wymienionych poniżej mogą wystąpić pewne problemy z wydajnością i wyjątki. Aby ułatwić testowanie, zachowaj tylko trzy produkty z identyfikatorami od 1 do 3.

  • Jedna z funkcji interfejsu API Products_GetAllProducts zwraca wyniki przez 5 sekund, natomiast oczekiwany czas odpowiedzi jest krótszy niż sekunda.

  • Podczas usuwania produktu z dowolnym z wymienionych powyżej identyfikatorów (od 1 do 3) otrzymujesz komunikat HTTP 500 — Wewnętrzny błąd serwera z poniższym komunikatem, wywołując operację Products_DeleteProduct .

    {
    "Komunikat": "Wystąpił błąd".
    }

  • Products_PutProduct operacji, która aktualizuje produkt jest nieoczekiwanie ograniczana, zgłaszając błąd HTTP 429 — zbyt wiele żądań z poniższym komunikatem o błędzie niezależnie od identyfikatora produktu i treści żądania, które wysyłasz w żądaniu. Jeśli na przykład klient aktualizuje cenę produktu "Pomidorowa zupa" o identyfikatorze produktu = 1 z poniższym treścią Json, otrzymuje kod stanu HTTP 429.

    Identyfikator parametru szablonu: 1
       Treść żądania: {"Name": "Zupa pomidorowa","Kategoria": "Artykuły spożywcze","Cena": 2,45}
       Treść odpowiedzi:
    {
    Przekroczono limit szybkości. Spróbuj ponownie po pewnym czasie.
    }

Kroki rozwiązywania problemów

  • Podczas rozwiązywania problemów z wydajnością najlepszą techniką izolacji błędów jest przechwytywanie [ślad inspektora APIM, który pokazuje czas potrzebny w każdej sekcji (przychodzący/ backend / wychodzący).

  • Jeśli przeanalizujesz ślad inspektora interfejsu API dla pierwszego problemu, zauważysz, że sekcja zaplecza zajmuje większość czasu (około 5 sekund), co oznacza, że w zapleczu odbywa się pewne spowolnienie lub długotrwała operacja.

    "source": "forward-request",
    "sygnatura czasowa": "2018-07-29T16:16:46.6615081Z",
    "upłynęło": "00:00:05.5844430","data": {
    "response": {
    "status": {
    "code": 200,
    "reason": "OK"
    }

  • Po odizolowaniu, że spowolnienie znajduje się w zapleczu, należy zbadać kod aplikacji zaplecza aplikacji internetowego interfejsu API. W przypadku scenariuszy, w których nie masz dostępu do zaplecza, możesz zaimplementować buforowanie na poziomie usługi APIM, jak pokazano poniżej. Dowiedz się, jak można zaimplementować zasady buforowania w celu zwiększenia wydajności w usłudze 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>

  • W przypadku drugiego problemu (HTTP 500 — wewnętrzny błąd serwera) wykonaj tę samą procedurę analizowania śledzenia inspektora usługi APIM i powinniśmy zobaczyć kod stanu HTTP 500 w obszarze atrybutu odpowiedzi "forward-request".

  • Oznacza to, że interfejs API zaplecza zwrócił http 500 z powodu nieobsługiwanego wyjątku w kodzie zaplecza, nie ma problemu na poziomie usługi APIM.

    forward-request (841.060 ms)
    {
    "response": {
    "status": {
    "code": 500,
    "reason": "Wewnętrzny błąd serwera"
    }

  • W przypadku trzeciego problemu (HTTP 429 — zbyt wiele żądań) wygląda na to, że osiągasz limit szybkości wywołań interfejsu API. Prawdopodobnie możesz sprawdzić, czy istnieją jakiekolwiek zasady "rate-limit" lub "rate-limit-by-key" zaimplementowane na poziomie operacji.

  • Jeśli nie możesz znaleźć żadnych takich zasad na poziomie operacji, kliknij przycisk Oblicz obowiązujące zasady , który wyświetli wszystkie dziedziczone zasady z różnych poziomów, podobnie jak niektóre zasady na poziomie produktu, które mogą powodować ten problem.

  • W tym miejscu należy zauważyć, że niektóre zasady są implementowane na poziomie interfejsu API, które naprawdę nie ograniczają szybkości wywołań interfejsu API, ale naśladują jej akcję, zwracając dostosowaną odpowiedź z powrotem do klienta przy użyciu zasad "return-response" i "set-status" w sekcji ruchu wychodzącego.

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

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.