Condividi tramite

Risolvere i problemi di prestazioni nelle chiamate API

  • Articolo

Facendo riferimento al blog su Azure Gestione API Troubleshooting Series, questo è il quarto scenario del lab. Assicurarsi di aver seguito le istruzioni di configurazione del lab in base a questa situazione, per ricreare il problema.

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 facilmente i record come e quando necessario. Tuttavia, è possibile riscontrare alcuni problemi di prestazioni ed eccezioni durante la chiamata delle operazioni API elencate di seguito. Per semplificare i test, mantenere solo tre prodotti con ID compresi tra 1 e 3.

  • Una delle funzioni API Products_GetAllProducts richiede 5 secondi per restituire i risultati, mentre il tempo di risposta previsto è inferiore a un secondo.

  • Durante l'eliminazione di un prodotto con uno degli ID indicati sopra (da 1 a 3), si riceve HTTP 500 - Errore interno del server con il messaggio seguente chiamando Products_DeleteProduct operazione.

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

  • Products_PutProduct'operazione che aggiorna un prodotto viene limitata in modo imprevisto, generando HTTP 429 - Troppe richieste con il messaggio di errore seguente indipendentemente dall'ID prodotto e dal corpo della richiesta, che si invia nella richiesta. Ad esempio, se il cliente aggiorna il prezzo del prodotto di "Tomato Soup" con ID prodotto = 1 con il corpo Json seguente ottiene il codice di stato HTTP 429.

    ID parametro 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.
    }

Passaggi per la risoluzione dei problemi

  • Durante la risoluzione dei problemi di prestazioni, la tecnica di isolamento degli errori migliore consiste nell'acquisire [traccia del controllo Gestione API che mostra il tempo impiegato in ogni sezione (Inbound/Backend/Outbound).

  • Se si analizza la traccia di Controllo API per il primo problema, si noterà che la sezione Back-end richiede la maggior parte del tempo (circa 5 secondi), il che significa che si sta verificando un'operazione a esecuzione prolungata o lenta nel back-end.

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

  • Dopo aver isolato che la lentezza si trova nel back-end, è necessario analizzare 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 indicato di seguito. Informazioni su come implementare i criteri di memorizzazione nella cache per migliorare le prestazioni in Azure Gestione API.

    <?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 il secondo problema (HTTP 500 - Errore interno del server), seguire la stessa procedura di analisi della traccia del controllo GESTIONE API e verrà visualizzato il codice di stato HTTP 500 nell'attributo di risposta "forward-request".

  • Ciò significa che l'API back-end ha restituito HTTP 500 a causa di un'eccezione non gestita nel codice back-end, non esiste alcun problema a livello di Gestione API.

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

  • Per il terzo problema (HTTP 429 - Troppe richieste), sembra che si stia raggiungendo il limite di frequenza delle chiamate API. Probabilmente è possibile verificare se è presente un criterio 'rate-limit' o 'rate-limit-by-key' implementato a livello di operazione.

  • Se non è possibile trovare tali criteri a livello di operazione, fare clic sul pulsante Calcola criteri effettivi , che mostrerà tutti i criteri ereditati da vari livelli, ad esempio alcuni criteri a livello di prodotto che possono causare questo problema.

  • In questo caso è necessario notare che alcuni criteri vengono implementati a livello di API che non limitano realmente la frequenza delle chiamate API, ma ne simulano l'azione restituendo una risposta personalizzata al client usando i criteri "return-response" e "set-status" nella sezione in uscita.

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

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.