Skip to content

Commit

Permalink
docs: clarify that the limiter max is the number of jobs, not their 1…
Browse files Browse the repository at this point in the history
…/1000ths. (#1926)
  • Loading branch information
ryanprince authored Dec 4, 2020
1 parent f6e8297 commit dbc08f2
Showing 1 changed file with 1 addition and 2 deletions.
3 changes: 1 addition & 2 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ as well as some other useful settings. All these settings are described in Bull'
It is possible to create queues that limit the number of jobs processed in a unit of time. The limiter is defined per queue, independently of the number of workers, so you can scale horizontally and still limiting the rate of processing easily:

```js
// Limit queue to max 1.000 jobs per 5 seconds.
// Limit queue to max 1000 jobs per 5000 milliseconds.
const myRateLimitedQueue = new Queue('rateLimited', {
limiter: {
max: 1000,
Expand Down Expand Up @@ -274,4 +274,3 @@ There are some important considerations regarding repeatable jobs:
- Bull is smart enough not to add the same repeatable job if the repeat options are the same. (CAUTION: A job id is part of the repeat options since: https://github.com/OptimalBits/bull/pull/603, therefore passing job ids will allow jobs with the same cron to be inserted in the queue)
- If there are no workers running, repeatable jobs will not accumulate next time a worker is online.
- repeatable jobs can be removed using the [removeRepeatable](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queueremoverepeatable) method.

0 comments on commit dbc08f2

Please sign in to comment.