Closed drygdryg closed 1 year ago
the problem with asynchronosity is it's... asynchronous - meaning context switching, job switching, and most of the time you wont know the time it takes for a concurrency task to complete.
Lets say you are sending a timeframe data using 'now()' to redis, think about what time exactly - in reality - the redis server will receive it, process it and return some response?
in synchronous context, it will be 'now() + network_latency'. network latency is already quite unpredictable by nature.
in asynchronous, it will be 'now() + any-concurrent-blocking task? + latency + some-more-concurrent-task + the-limiter-proceeding-logic' - and by time we reach the proceeding logic, the limiter state might already be badly tampered by the slippage of time.
from my understanding, thats not nice and not easy to handle - which is why there is no way to include async-redis with the current logic of this library - at least to my knowledge.
feel free to correct me if im wrong. thanks
Resolved in the new major release!
I found that Pyrate-limiter uses a synchronous Redis connection under the hood, even for asynchronous ratelimiter decorator. Is it possible to use async Redis connection pool with Pyrate-limiter and is there any performance-related reasons for using asynchronous Redis connection in a fully asynchronous application?