Udostępnij za pośrednictwem

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

  • Artykuł

Odwołując się do bloga w usłudze Azure API Management Troubleshooting Series, jest to czwarty scenariusz laboratorium. Upewnij się, że zostały wykonane instrukcje konfiguracji laboratorium zgodnie z tym, aby ponownie utworzyć problem.

Oryginalna wersja produktu: API Management Service
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 w razie potrzeby łatwo tworzyć, odczytywać, aktualizować i usuwać rekordy. Mogą jednak wystąpić pewne problemy z wydajnością i wyjątki podczas wywoływania operacji interfejsu API wymienionych poniżej. Aby ułatwić testowanie, zachowaj tylko trzy produkty o identyfikatorach od 1 do 3.

  • Jedna z funkcji interfejsu API Products_GetAllProducts zwraca wyniki przez 5 sekund, podczas gdy oczekiwany czas odpowiedzi wynosi mniej niż sekundę.

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

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

  • Products_PutProduct operacja, która aktualizuje produkt, jest nieoczekiwanie ograniczana, zgłaszając protokół 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 zaktualizuje cenę produktu "Zupa pomidorowa" o identyfikatorze produktu = 1 z poniższą treścią kodu JSON, otrzyma kod stanu HTTP 429.

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

Czynności umożliwiające rozwiązywanie problemów

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

  • Jeśli przeanalizujesz ślad Inspektora interfejsu API pod kątem pierwszego problemu, zauważysz, że sekcja Zaplecze zajmuje większość czasu (około 5 sekund), co oznacza, że w zapleczu jest wykonywana pewna powolność lub długotrwała operacja.

    "source": "forward-request",
    "sygnatura czasowa": "2018-07-29T16:16:46.6615081Z",
    "elapsed": "00:00:05.5844430","data": {
    "odpowiedź": {
    "status": {
    "kod": 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 poniżej. Przeczytaj o tym, jak 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 powinien zostać wyświetlony kod stanu HTTP 500 w atrybucie odpowiedzi "forward-request".

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

    forward-request (841.060 ms)
    {
    "odpowiedź": {
    "status": {
    "kod": 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źć 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, co tak naprawdę nie ogranicza szybkości wywołań interfejsu API, ale naśladuje jego działanie, 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 platformy Azure.