Job throughput with concurrency limits
@bgentry is already working on this.
Since Feb 13, 2026.
- Dominant language
- Go
- Stars
- 5.7k
- Forks
- 179
- Avg merge
- 15h 43m
- Merged PRs (30d)
- 13
Description
Hi, we recently moved to River Pro version and decided to add global limits for one of our queues. The queue is processed by 4 client instances that each have 10 max workers and the only change in the configuration is the added global limit of 40.
The jobs themselves are pretty fast at an average of ~5 seconds. Before adding the global limits we used to see a throughput of ~33k jobs per hour and afterwards it dropped to ~17k per hour. A couple of immediate tests with a larger worker pool didn't make any difference.
We would expect a slowdown to a certain degree from the added coordination overhead combined with fast jobs but this seems a bit extreme.
Do you have any info on what the expected throughput slowdowns are when using concurrency limits? Happy to give more info if it helps, thanks!
River versions:
github.com/riverqueue/river v0.30.2
github.com/riverqueue/river/riverdriver/riverpgxv5 v0.30.2
riverqueue.com/riverpro v0.21.0
riverqueue.com/riverpro/driver/riverpropgxv5 v0.21.0
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.