Risolvere i problemi di prestazioni Gestione API di Azure nelle chiamate API

Sommario

Questo articolo illustra come risolvere i problemi di prestazioni Gestione API di Azure nelle chiamate API, tra cui la latenza back-end e gli errori HTTP 500 e 429. Usare questi passaggi per isolare gli errori e migliorare i tempi di risposta dell'API.

Questo articolo è il quarto scenario del lab della serie di risoluzione dei problemi Gestione API di Azure. Assicurarsi di seguire le istruzioni di configurazione del lab in base alle istruzioni del lab della serie di risoluzione dei problemi di Gestione API.

Versione originale del prodotto: servizio Gestione API
Numero KB originale: 4464929

Sintomi

L'API ProductStore in Gestione API comunica con l'endpoint back-end (https://productstoreapp.azurewebsites.net) per creare, leggere, aggiornare ed eliminare i record in base alle esigenze. Tuttavia, è possibile che si verifichino problemi di prestazioni ed eccezioni quando si eseguono le operazioni API seguenti.

• Products_GetAllProducts richiede cinque secondi per restituire i risultati, ma il tempo di risposta previsto è inferiore a un secondo.

• Quando si usa l'operazione di Products_DeleteProduct per eliminare un prodotto con uno degli ID menzionati in precedenza (uno o tre), viene visualizzato un errore HTTP 500 - Interno del server con il messaggio seguente:

  "Message": "Si è verificato un errore".

• Un'operazione che aggiorna un prodotto viene limitata in modo imprevisto e genera un errore HTTP 429 - Troppe richieste . Questo errore si verifica indipendentemente dall'ID prodotto e dal corpo della richiesta. Ad esempio, se il cliente aggiorna il prezzo del prodotto "Zuppa di pomodoro" con l'ID prodotto impostato su uno usando l'esempio seguente, ottiene un codice di stato HTTP 429.

  ID parametro del modello: 1
     Corpo della richiesta: {"Name": "Zuppa di pomodoro","Categoria": "Generi alimentari","Prezzo": 2.45}
     Corpo della risposta:
  {
  Il limite di velocità è stato superato. Riprovare dopo qualche tempo.
  }

Risoluzione dei problemi

Durante la risoluzione dei problemi di prestazioni, il modo migliore per isolare gli errori consiste nell'acquisire una traccia di controllo di Gestione API che mostra il tempo impiegato per ogni sezione (Inbound, Backend e Outbound).

Products_GetAllProducts latenza

Se si analizza la traccia di Controllo API per questo problema, si noterà che il back-end richiede più tempo (circa cinque secondi). Questo risultato indica una certa lentezza o un'operazione a esecuzione prolungata nel back-end.This result means there's some slowness or a long running operation on the backend. L'esempio seguente mostra il tempo di risposta del backend nella traccia di API Inspector:

"source": "richiesta di inoltro"
"timestamp": "2018-07-29T16:16:46.6615081Z",
"tempo trascorso": "00:00:05.5844430",
"data": {
"response": {
"status": {
"code": 200,
"reason": "OK" }

Dopo aver isolato che la lentezza si verifica nel back-end, è necessario esaminare il codice dell'applicazione back-end dell'applicazione API Web. Per gli scenari in cui non si ha accesso al back-end, è possibile implementare la memorizzazione nella cache a livello di Gestione API, come illustrato nell'esempio seguente.

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

Per altre informazioni sulla memorizzazione nella cache, vedere Aggiungere la memorizzazione nella cache per migliorare le prestazioni in Gestione API di Azure.

Products_DeleteProduct HTTP 500 errore interno del server

Per questo problema, seguire la stessa procedura per analizzare la traccia dell'ispettore di API Management. È probabile che venga visualizzato un codice di stato HTTP 500 sotto l'attributo forward-request di risposta.

Questo codice di stato indica che l'API back-end restituisce HTTP 500 a causa di un'eccezione non gestita nel codice back-end. Non esiste alcun problema a livello di Gestione API, come illustrato nell'esempio seguente:

richiesta-inoltrata (841.060 ms)
{
"response": {
"stato": {
"code": 500,
"reason": "Errore interno del server"
}

Products_PutProduct errore HTTP 429: troppe richieste

Per questo problema, sembra che si stia raggiungendo un limite di frequenza delle chiamate API. Controllare se sono presenti rate-limit criteri o rate-limit-by-key implementati a livello di operazione.

Se non trovi criteri di questo tipo a livello di operazione, seleziona Calcola criterio effettivo. Questa azione mostra tutti i criteri ereditati da vari livelli, inclusi i criteri a livello di prodotto che possono causare questo problema.

Potrebbero essere visualizzati alcuni criteri implementati a livello di API che non limitano effettivamente la frequenza delle chiamate API. Simula invece le sue azioni restituendo al client una risposta personalizzata tramite i criteri return-response e set-status per la sezione Outbound, come illustrato nell'esempio seguente:

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