From 019d7c7de42c10e5f2e86ab4aa771816c735f947 Mon Sep 17 00:00:00 2001 From: Yusuke Sangenya Date: Wed, 11 Dec 2024 22:35:21 +0900 Subject: [PATCH] Add note about `threads` --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index d1c9dd0f..bc8d8575 100644 --- a/README.md +++ b/README.md @@ -178,6 +178,7 @@ Here's an overview of the different options: Check the sections below on [how queue order behaves combined with priorities](#queue-order-and-priorities), and [how the way you specify the queues per worker might affect performance](#queues-specification-and-performance). - `threads`: this is the max size of the thread pool that each worker will have to run jobs. Each worker will fetch this number of jobs from their queue(s), at most and will post them to the thread pool to be run. By default, this is `3`. Only workers have this setting. +It is recommended to set this value less than or equal to the queue database's connection pool size minus 2, as each worker thread uses one connection, and two additional connections are reserved for polling and heartbeat. - `processes`: this is the number of worker processes that will be forked by the supervisor with the settings given. By default, this is `1`, just a single process. This setting is useful if you want to dedicate more than one CPU core to a queue or queues with the same configuration. Only workers have this setting. - `concurrency_maintenance`: whether the dispatcher will perform the concurrency maintenance work. This is `true` by default, and it's useful if you don't use any [concurrency controls](#concurrency-controls) and want to disable it or if you run multiple dispatchers and want some of them to just dispatch jobs without doing anything else.