Introducing the consume feature to this ratelimiter module.
A common feature of ratelimiters is to be able to limit an execution at a rate of a specific unit metric rather than the execution of an operation as a whole. So far, this ratelimiter module can limit the number that a block of code is executed within a defined period of time.
However imagine the case of producing a stream of data, and we want to cap it at 5kb per second. For generating this stream of data we have a block of code that iteratively implements this task. With the current ratelimiter, we need to calculate ourselves the amount of bytes each iteration generates, and adjust the max_calls attribute accordingly.
For example:
Hypothesis:
Target rate: 5kb/s
Block of code that iterates and performs the task: do_something()
Solution using ratelimiter without the consume feature:
We have to estimate how many kb each iteration of do_something() generates. Then we have to divide 5kb/s with this estimation in order to derive the max_calls attribute that we need to set for our ratelimiter object.
And this will only work with the assumption that each do_something() generates constant amount of kb.
This fork introduces the consume attribute of the ratelimiter object which specifies how many elements are to be appended in the calls deque in every execution wrapped by the ratelimiter. All the elements appended in each execution share the same timestamp. The consume attribute can be modified during each execution to adapt in varying rate demands.
I have included examples and some further descriptions in the updated readme within my fork.
Testing
The consume addition does not affect the existing tests as all pass successfully. I'have also added extensive new test cases to cover all aspects of the new feature.
Async is not affected at all by this change.
To sum up, I believe this is an essential feature for every ratelimiter (other popular rate limiters also include it: Java) and thought it would be useful to add it. Let me know your thoughts.
Introducing the consume feature to this ratelimiter module.
A common feature of ratelimiters is to be able to limit an execution at a rate of a specific unit metric rather than the execution of an operation as a whole. So far, this ratelimiter module can limit the number that a block of code is executed within a defined period of time. However imagine the case of producing a stream of data, and we want to cap it at 5kb per second. For generating this stream of data we have a block of code that iteratively implements this task. With the current ratelimiter, we need to calculate ourselves the amount of bytes each iteration generates, and adjust the max_calls attribute accordingly.
For example: Hypothesis:
Solution using ratelimiter without the consume feature: We have to estimate how many kb each iteration of do_something() generates. Then we have to divide 5kb/s with this estimation in order to derive the max_calls attribute that we need to set for our ratelimiter object.
And this will only work with the assumption that each do_something() generates constant amount of kb.
This fork introduces the consume attribute of the ratelimiter object which specifies how many elements are to be appended in the calls deque in every execution wrapped by the ratelimiter. All the elements appended in each execution share the same timestamp. The consume attribute can be modified during each execution to adapt in varying rate demands.
I have included examples and some further descriptions in the updated readme within my fork.
Testing
The consume addition does not affect the existing tests as all pass successfully. I'have also added extensive new test cases to cover all aspects of the new feature.
Async is not affected at all by this change.
To sum up, I believe this is an essential feature for every ratelimiter (other popular rate limiters also include it: Java) and thought it would be useful to add it. Let me know your thoughts.