Inclusion de un ratelimit usando cache
Necesitaba un ratelimit que estuviera disponible en todos los workers, cosa que aparentemente la libreria que estaba usando no tomaba en cuenta asi que la mejor idea que tuve es aprovechar el cache y usarlo para generar el ratelimit :3 asi que como todos los workers se comunican con el mismo cache, todos van a compartir el mismo lock
This commit is contained in:
33
utils/ratelimit.py
Normal file
33
utils/ratelimit.py
Normal file
@@ -0,0 +1,33 @@
|
||||
"""Modulo encargado de la función de ratelimit"""
|
||||
|
||||
import time
|
||||
import logging
|
||||
|
||||
from django.core.cache import cache
|
||||
from django.utils import timezone
|
||||
|
||||
_log = logging.getLogger('utils_ratelimit')
|
||||
_log.addHandler(logging.NullHandler())
|
||||
|
||||
|
||||
def ratelimit():
|
||||
"""Rate limit básico, espera un segundo entre ejecuciones
|
||||
|
||||
Esto lo logra a través del cache, utilizando la key musicbrainz_ratelimit_SS en donde SS es el
|
||||
segundo actual, si es que ya esta seteada la key, se esperaran 0.001 segundos, y se volverá a
|
||||
intentar
|
||||
"""
|
||||
while not cache.set(
|
||||
f'musicbrainz_ratelimit_{timezone.now().second}',
|
||||
'locked <3',
|
||||
nx=True,
|
||||
timeout=10):
|
||||
# Le tengo algo de respeto a este sleep, si es demasiado corto igual y es un busy
|
||||
# loop y eso es horrible para el rendimiento, pero si es muy largo igual pierdo demasiadas
|
||||
# oportunidades de obtener un lock.
|
||||
# Ademas la precision de sleep depende del sistema operativo, supuestamente linux es mejor
|
||||
# para llevar esto, pero no estoy nada seguro~
|
||||
# https://stackoverflow.com/questions/1133857/how-accurate-is-pythons-time-sleep
|
||||
time.sleep(0.001)
|
||||
|
||||
_log.debug('Ratelimit allowing request on second %s', timezone.now().second)
|
||||
Reference in New Issue
Block a user