Síntomas
El almacén de productos de API en APIM se comunica con el punto de conexión de back-end (https://productstoreapp.azurewebsites.net
) para crear, leer, actualizar y eliminar registros fácilmente cuando sea necesario. Sin embargo, es posible que se enfrente a algunos problemas de rendimiento y excepciones al invocar las operaciones de API que se enumeran a continuación. Para facilitar las pruebas, mantenga solo tres productos con identificadores que van de 1 a 3.
-
Una de las funciones de API Products_GetAllProducts tarda 5 segundos en devolver los resultados, mientras que el tiempo de respuesta esperado es inferior a un segundo.
-
Al eliminar un producto que tenga cualquiera de los identificadores mencionados anteriormente (de 1 a 3), obtendrá HTTP 500- Error interno del servidor con el mensaje siguiente llamando a Products_DeleteProduct operación.
{
"Message": "Se ha producido un error".
} -
Products_PutProduct operación que actualiza un producto se está limitando inesperadamente, generando HTTP 429: demasiadas solicitudes con el siguiente mensaje de error independientemente del identificador del producto y el cuerpo de la solicitud, que envíe en la solicitud. Por ejemplo, si el cliente actualiza el precio del producto de "Sopa de tomate" con id. de producto = 1 con el siguiente cuerpo Json, obtiene el código de estado HTTP 429.
Id. de parámetro de plantilla: 1
Cuerpo de la solicitud: {"Name": "Sopa de tomate", "Categoría": "Comestibles", "Precio": 2.45}
Cuerpo de la respuesta:
{
Se supera el límite de velocidad. Inténtelo de nuevo después de algún tiempo.
}
-
Mientras se solucionan problemas de rendimiento, la mejor manera de capturar la técnica de aislamiento de errores es capturar [seguimiento del inspector de APIM que muestra el tiempo necesario en cada sección (entrante/ back-end/saliente).
-
Si analiza el seguimiento del Inspector de API para el primer problema, observaría que la sección Back-end tarda la mayor parte del tiempo (aproximadamente 5 segundos), lo que significa que hay cierta lentitud o que se está llevando a cabo una operación de larga duración en el back-end.
"source": "forward-request",
"timestamp": "2018-07-29T16:16:46.6615081Z",
"elapsed": "00:00:05.5844430","data": {
"response": {
"status": {
"code": 200,
"reason": "OK"
} -
Una vez que haya aislado que la lentitud está en el back-end, debe investigar el código de la aplicación back-end de la aplicación de API web. En escenarios en los que no tiene acceso al back-end, puede implementar el almacenamiento en caché en el nivel de APIM como se muestra a continuación. Obtenga información sobre cómo implementar directivas de almacenamiento en caché para mejorar el rendimiento en 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> -
Para el segundo problema (HTTP 500 - Error interno del servidor), siga el mismo procedimiento de análisis del seguimiento del inspector de APIM y deberíamos ver el código de estado HTTP 500 en el atributo de respuesta "forward-request".
-
Esto significa que la API de back-end devolvió HTTP 500 debido a que se produjo alguna excepción no controlada en el código back-end, no hay ningún problema en el nivel de APIM.
forward-request (841.060 ms)
{
"response": {
"status": {
"code": 500,
"reason": "Internal Server Error"
} -
Para el tercer problema (HTTP 429 : demasiadas solicitudes), parece que está alcanzando el límite de velocidad de llamadas API. Probablemente puede comprobar si hay alguna directiva "rate-limit" o "rate-limit-by-key" implementada en el nivel de operación.
-
Si no encuentra ninguna de estas directivas en el nivel de operación, haga clic en el botón Calcular directiva efectiva , que mostrará todas las directivas heredadas de varios niveles, como puede tener algunas directivas en el nivel de producto que pueden causar este problema.
-
Aquí debe observar que algunas directivas se implementan en el nivel de API, lo que no limita realmente la tasa de llamadas api, sino que imita su acción devolviendo una respuesta personalizada al cliente mediante directivas "return-response" y "set-status" en la sección saliente.
<?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>