Different limits for the same concurrency name do not allow for dynamic configuration
Hello,
We used this gem successfully to limit our jobs but we encounter a use-case that seems difficult to handle: dynamic limiting. We have a dynamic number of servers and we want to limit jobs to run on at most 90% of available servers. We first implemented a naive implementation:
concurrency = RedisThrottle.concurrency(:key_for_job, limit: 90 * number_of_workers / 100, ttl: 3600)
concurrency.acquire(REDIS)
Unfortunately, because the key use by the concurrency strategy depends on the limit, we loose all historical data when number_of_workers
changes and ultimately the limit is not applied correctly.
At first it seemed that I could simply suggest a MR removing the limit from api.lua
, but it seems that it breaks other functionalities like INFO.
- Do you think it would make sense to have the limit only identified with the name of the strategy?
- If we were to do so, we'd need to remove the
.info
fromRedisThrottle
class, and only use.info
on instances. This would mean backward incompatible changes... - Final question though: Do you see another way to achieve dynamic limiting?