¿Cómo se define el tiempo de espera (timeout) de una API, recurso u operación y cómo funciona?

El tiempo de espera de una llamada es el tiempo total disponible para que una petición sea procesada y respondida. Cuando se recibe una petición pero el backend no envía una respuesta dentro del tiempo disponible, la llamada se aborta y se devuelve el error 504.

¿Cómo se define el tiempo de espera en Sensedia API Platform?

El tiempo de espera de las peticiones se establece en más de un lugar en la Plataforma y existe una jerarquía:

El gateway funciona con un tiempo de espera por defecto de 60 segundos.
Es posible definir un tiempo de espera específico para una API, un recurso y/o una operación. Esta definición puede hacerse por valor en segundos o por variable de entorno. En este caso, el tiempo de espera más específico prevalece sobre el tiempo de espera más genérico, pero siempre se respetará el tiempo de espera del gateway.
Ejemplo de esta operación:

Imagine que crea una API con dos recursos: /resource1 y /resource2. Para el conjunto de la API, se establece un tiempo de espera de 30 segundos. En el recurso /resource1, se establece un tiempo de espera de 10 segundos para el recurso en su conjunto, pero también se establece un tiempo de espera de 40 segundos para la operación POST y un tiempo de espera de 20 segundos para la operación GET. Se crea otra operación para este recurso, una operación PUT, pero no se establece ningún tiempo de espera específico para ella. También no se establece ningún tiempo de espera para el recurso /resource2.

¿Qué tiempo de espera será válido para cada recurso?
El /resource1 tiene varias operaciones: GET seguirá el tiempo de espera de 10 segundos que se estableció y POST seguirá el tiempo de espera de 40 segundos. La operación PUT no tiene establecido ningún tiempo de espera, por lo que seguirá el tiempo de espera de 10 segundos del recurso.

El /resource2 no tiene establecido ningún tiempo de espera. Por lo tanto, seguirá el tiempo de espera establecido para la API, que era de 30 segundos. Todas las operaciones en el recurso seguirán este tiempo de espera, a menos que se establezca un valor diferente para cada operación.

Configuración de los valores de tiempo de espera

Ahora que comprende la herencia de los tiempos de espera, vale la pena detallar dónde y cómo se establecen los valores.

Tiempo de espera por defecto del gateway

El tiempo de espera del gateway tiene un valor por defecto de 60 segundos y no puede ser modificado por los usuarios. Este valor está calculado para ser más que suficiente para las peticiones HTTP y trabajar con valores más altos puede significar un gran compromiso de rendimiento.

¿Por qué un tiempo de espera elevado compromete el rendimiento?: Para que los gateways sean escalables y fiables, trabajamos con límites de rendimiento que protegen todo el ecosistema de APIs. El tiempo de espera es una de las herramientas que ayuda a proteger el sistema evitando la acumulación excesiva de peticiones que se procesan al mismo tiempo (lo que llamamos threads). Si tienes una API que llega a un backend lento y aumentas el tiempo de espera para asegurarte de que el backend es capaz de responder a las peticiones, esto genera un aumento de threads. Cuando se alcanza el límite de procesamiento del gateway, las peticiones entrantes se bloquean, incluso si son para APIs que tienen un tiempo de espera menor. En otras palabras, el buen gobierno de las APIs requiere parsimonia en cuanto al tiempo de espera de todo su ecosistema.

Tiempo de espera de las APIs, recursos y operaciones

El establecimiento de valores de tiempo de espera específicos para una API, un recurso o una operación se realiza en el flujo de una API (APIs API deseada Edit Flows).

En la pantalla de edición del flujo, el valor del tiempo de espera se introduce en la ventana API Destination, que es el elemento 3 en la imagen siguiente. Mediante los elementos 1 y 2 de la imagen definimos si la configuración del destino de la API a la que estamos accediendo se refiere a todos los recursos de una API o a un recurso específico (elemento 1 — campo Resources) y a todas las operaciones de un recurso o a una operación específica (elemento 2 — campo Operations):

Al abrir la ventana API Destination, épuede rellenar el campo Timeout con el valor en segundos o con una variable de entorno.

El valor introducido se respetará si es menor o igual que el tiempo de espera del gateway. Si no se introduce ningún valor, el gateway considerará el próximo valor en la jerarquía explicada anteriormente.

¿Cuándo incluir una variable de entorno?

Puedes establecer el tiempo de espera como una variable de entorno. En este caso, debe incluir el nombre de la variable en el campo Timeout, pero el valor en sí debe establecerse en Environments entorno elegido Environment Variables. En este caso, el valor será único para el entorno que contiene la variable registrada.

Cuando el tiempo de espera se establece mediante una variable de entorno, se puede:

Incluir la variable en varias APIs/recursos/operaciones diferentes. Si desea anular el valor del tiempo de espera de todos estos objetos al mismo tiempo, simplemente cambia el valor de la variable en el entorno, sin tener que abrir cada objeto para hacer el cambio.
Definir distintos tiempos de espera en función del entorno de despliegue de una API. Por ejemplo, puede incluir en la ventana API Destination el tiempo de espera como una variable llamada timeout. Entonces puede incluir la variable timeout en dos entornos diferentes — digamos «Env1» y «Env2» — pero en cada entorno introducir un valor diferente (10 segundos para «Env1» y 20 segundos para «Env2»). Cuando la API se despliega en «Env1», su tiempo de espera será de 10 segundos, pero cuando se despliega en «Env2», será de 20 segundos.

Vea más sobre variables de entorno aquí.

En este caso se aplican las mismas consideraciones de rendimiento relativas al tiempo de espera del gateway que hemos planteado anteriormente. Siempre que registre un valor de tiempo de espera alto para una API/recurso/operación, debe tener en cuenta el compromiso del rendimiento y el aumento del riesgo de indisponibilidad de las APIs si su backend no puede responder rápidamente a las peticiones entrantes.

Thanks for your feedback!

EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]