Solucionar problemas de rendimiento del servicio Azure API Management en las llamadas a la API

Resumen

En este artículo se explica cómo solucionar problemas de rendimiento Azure API Management en las llamadas API, incluida la latencia de back-end y los errores HTTP 500 y 429. Siga estos pasos para aislar los errores y mejorar los tiempos de respuesta de la API.

Este artículo es el cuarto caso del laboratorio de la serie de resolución de problemas de Azure API Management. Asegúrese de seguir las instrucciones de configuración del laboratorio de acuerdo con las instrucciones del laboratorio de la serie de resolución de problemas de API Management.

Versión original del producto: servicio API Management
Número de KB original: 4464929

Síntomas

Api ProductStore en API Management se comunica con el punto de conexión de back-end (https://productstoreapp.azurewebsites.net) para crear, leer, actualizar y eliminar registros según sea necesario. Sin embargo, es posible que encuentre problemas de rendimiento y excepciones al realizar las siguientes operaciones de API.

Note

Para obtener los mejores resultados de las pruebas, mantenga solo tres productos con identificadores que van de uno a tres.

  • Products_GetAllProducts tarda cinco segundos en devolver resultados, pero el tiempo de respuesta esperado es menor que un segundo.

  • Al usar la operación de Products_DeleteProduct para eliminar un producto con cualquiera de los identificadores mencionados anteriormente (uno a tres), obtendrá un error HTTP 500 - Servidor interno con el siguiente mensaje:

    "Mensaje": "Se ha producido un error".

  • Una operación que actualiza un producto se limita inesperadamente y da como resultado un error HTTP 429: demasiadas solicitudes . Este error se produce independientemente del identificador del producto y del cuerpo de la solicitud. Por ejemplo, si el cliente actualiza el precio del producto de "Sopa de tomate" con el identificador de producto establecido en uno mediante el ejemplo siguiente, obtienen un código de estado HTTP 429.

    Identificador de parámetro de plantilla: 1
       Cuerpo de la solicitud: {"Name": "Sopa de tomate","Categoría": "Comestibles","Precio": 2.45}
       Cuerpo de la respuesta:
    {
    Rate limit is exceeded. (El límite de velocidad se ha excedido.) vuelva a intentarlo más tarde.
    }

Solución de problemas

Al solucionar problemas de rendimiento, la mejor manera de aislar los errores es capturar un seguimiento del inspector de API Management que muestra el tiempo necesario para cada sección (entrante, back-end y saliente).

latencia de Products_GetAllProducts

Si analiza el seguimiento del Inspector de API para este problema, verá que el back-end tarda más tiempo (aproximadamente cinco segundos). Este resultado significa que hay cierta lentitud o una operación prolongada en el backend. En el ejemplo siguiente se muestra el tiempo de respuesta del back-end en el seguimiento del Inspector de API:

"solicitud-reenviar"
"timestamp": "2018-07-29T16:16:46.6615081Z",
"transcurrido": "00:00:05.5844430",
"data": {
"response": {
"estado": {
"code": 200,
"reason": "OK" }

Una vez que determine que la lentitud está en el backend, debe investigar el código de backend de la aplicación de la API web. En escenarios en los que no tiene acceso al back-end, puede implementar el almacenamiento en caché en el nivel de API Management, como se muestra en el ejemplo siguiente.

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

Para obtener más información sobre el almacenamiento en caché, consulte Agregar almacenamiento en caché para mejorar el rendimiento en Azure API Management.

Products_DeleteProduct error interno del servidor HTTP 500

Para este problema, siga el mismo procedimiento para analizar el seguimiento del inspector de API Management. Es probable que vea un código de estado HTTP 500 en el forward-request atributo de respuesta.

Este código de estado significa que la API de back-end devuelve HTTP 500 debido a una excepción no controlada en el código de back-end. No hay ningún problema en el nivel de API Management, como se muestra en el ejemplo siguiente:

solicitud de reenvío (841.060 ms)
{
"response": {
"estado": {
"code": 500,
"reason": "Error interno del servidor"
}

Products_PutProduct error HTTP 429 de demasiadas solicitudes

En este caso, parece que has alcanzado un límite de tasa de llamadas a la API. Compruebe si hay alguna rate-limit directiva o rate-limit-by-key implementada en el nivel de operación.

Si no encuentra ninguna directiva como esa en el nivel de operación, seleccione Calcular directiva efectiva. Esta acción muestra todas las directivas heredadas de varios niveles, incluidas las directivas en el nivel de producto que pueden causar este problema.

Es posible que vea algunas directivas que se implementan en el nivel de API que realmente no limitan la tasa de llamadas api. En su lugar, imita sus acciones devolviendo al cliente una respuesta personalizada mediante las directivas return-response y set-status para la sección Salida, como se muestra en el siguiente ejemplo:

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