¿Cuál es la diferencia entre los interceptores Rate Limit y Spike Arrest?
Tanto el interceptor de Rate Limit como el Spike Arrest se utilizan para controlar la cantidad de peticiones aceptadas por una API, recurso u operación. Sin embargo, gestionan este control de maneras diferentes:
Rate Limit | Spike Arrest |
---|---|
Rate Limit funciona en función de los intervalos de tiempo (segundo, minuto, hora, día, mes). Comprueba si el número de llamadas dentro del intervalo configurado está dentro del límite esperado, independientemente del tiempo entre las llamadas. Cuando termina el intervalo, comienza un nuevo y el recuento de llamadas se reinicia. |
Spike Arrest garantiza una distancia de tiempo mínima entre dos llamadas. Si no se respeta el tiempo entre dos peticiones, a segunda solicitud no será atendida y resultará en un error HTTP 429. Esta operación evita picos de tráfico y protege el servidor, garantizando un flujo entrada manejable. |
¿Cuándo usar cada uno?
Para garantizar límites generales, Rate Limit es el más adecuado. También se puede utilizar para reducir los picos de tráfico en ventanas de segundos, pero es más efectivo para tráficos relativamente espaciados.
Si su objetivo es proteger el servidor contra la sobrecarga y el tráfico intenso, Spike Arrest ofrece un mejor control.
¿Cómo configurarlos?
Para configurar los interceptores, es importante entender la lógica de funcionamiento de cada uno. Dado que Spike Arrest funciona con intervalos entre llamadas, configurarlo con un límite de 1 petición por segundo, 60 por minuto o 3600 por hora resultará en el mismo comportamiento, ya que el intervalo mínimo será el mismo.
Rate Limit requiere más atención en la configuración porque opera en base al número total de llamadas en un intervalo de tiempo. Así, configurar un límite de 1 solicitud por segundo es diferente de 60 por minuto, ya que en el primer caso, el conteo se renueva cada segundo, y en el segundo, cada minuto. Vea los ejemplos a continuación para entender mejor.
Ejemplos de uso: Spike Arrest
-
Límite de 6 solicitudes por minuto: tenemos un Spike Arrest configurado para 6 solicitudes por minuto, resultando en un intervalo mínimo de 10 segundos entre llamadas. Las llamadas aceptadas se muestran en morado y las denegadas en naranja:
Las llamadas solo se aceptan si se realizan regularmente, con el intervalo mínimo entre ellas.
-
Límite de 1 solicitud por segundo: Spike Arrest está configurado para 1 solicitud por segundo (equivalente a 60 por minuto). Consideramos 100 solicitudes realizadas en 1 minuto. Las llamadas aceptadas se muestran en morado y las llamadas denegadas en naranja:
En total, se aceptaron 45 de las 100 llamadas, respetando el intervalo entre ellas y evitando picos de tráfico, distribuyendo mejor las llamadas.
Ejemplos de uso: Rate Limit
-
Límite de 1 solicitud por segundo: Rate Limit está limitado a 1 solicitud por segundo. Las llamadas aceptadas se muestran en morado y las llamadas denegadas en naranja:
Si las llamadas exceden el límite configurado en el intervalo definido, Rate Limit atenderá un número de solicitudes dentro del límite. Este escenario se muestra en el gráfico a continuación, representando 1 minuto de funcionamiento de Rate Limit con 100 solicitudes realizadas.
En este caso, Rate Limit atendió 55 de las 100 llamadas. Esto ocurre porque, a diferencia de Spike Arrest, Rate Limit permite llamadas muy cercanas, siempre y cuando una ocurra al final de una ventana y la otra al comienzo de la siguiente.
-
Límite de 60 solicitudes por minuto: En este escenario, Rate Limit acepta hasta 60 solicitudes por minuto. Como el recuento de llamadas se reinicia solo al final del período, el funcionamiento es diferente de la configuración anterior (1 solicitud por segundo). Nuevamente, representamos 100 llamadas durante 1 minuto. Como era de esperar, Rate Limit aceptó 60 solicitudes:
Se permiten picos de tráfico dentro del límite total de llamadas en el período. Si se supera el límite, la API (o recurso o operación) estará indisponible hasta que se inicie el nuevo intervalo de tiempo. En el ejemplo anterior, como ocurrió la petición 60a justo antes del segundo 33, la indisponibilidad duraría los 27 segundos.
Share your suggestions with us!
Click here and then [+ Submit idea]