You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This task is for implementing rate-limiting in Conveyor MQ and assessing the various implementation options and their trade-offs.
Implementations
Queues can either be rate-limited on the producer side or the consumer side.
Producer side
Rate limiting on the producer side requires that tasks be scheduled according to the rate limit constraints, and then enqueued by an orchestrator.
Pros
Task rate is centrally constrained in the queue
No complexity in consumers/workers
Cons
Stateful
Complexity in enqueuing/scheduling task
Bound by orchestrator interval
Consumer side
Rate limiting on the consumer side requires that tasks are only taken from the queue for processing at the required rate by having the consumers/workers coordinate when they can and cannot take a task and process it.
Pros
Not stateful
No complexity when enqueuing/scheduling tasks, or orchestrating the queue.
Cons
Extra overhead is added to consumers/workers to coordinate when the can & cannot take a task to process, + state for this.
The text was updated successfully, but these errors were encountered:
(Not suggesting that this is a user-space problem: just mentioning libs that might help with adding this feature to Conveyor)
Hi @eugene1g :) Thanks for mentioning these, this is most certainly useful knowing about Tarn.js and async-sema and keeping this in mind when thinking about how to solve rate-limiting in Conveyor.
Description
This task is for implementing rate-limiting in Conveyor MQ and assessing the various implementation options and their trade-offs.
Implementations
Queues can either be rate-limited on the producer side or the consumer side.
Producer side
Rate limiting on the producer side requires that tasks be scheduled according to the rate limit constraints, and then enqueued by an orchestrator.
Pros
Cons
Consumer side
Rate limiting on the consumer side requires that tasks are only taken from the queue for processing at the required rate by having the consumers/workers coordinate when they can and cannot take a task and process it.
Pros
Cons
The text was updated successfully, but these errors were encountered: