http: limit RPC server threads to available cores #33678

1. 
   furszy commented at 1:33 pm on October 22, 2025: member

   The HTTP server currently spawns 16 threads by default, regardless of the system’s available ones. This change limits the number of threads in the RPC server to the number of available CPUs, preventing excessive context switching and improving overall responsiveness on systems with fewer cores. If -rpcthreads exceeds that limit, it is adjusted to num_cores - 1 and a warning is logged.
2. http: limit RPC server threads to available cores

   The HTTP server previously spawned 16 threads by default, regardless
   of the system’s available ones. This change limits the number of RPC
   threads to the number of available CPUs, preventing excessive context
   switching and improving overall responsiveness on systems with fewer
   cores.
   If -rpcthreads exceeds that limit, it is adjusted to num_cores - 1
   and a warning is logged.

   8e2a96b830
3. DrahtBot added the label RPC/REST/ZMQ on Oct 22, 2025
4. 
   DrahtBot commented at 1:33 pm on October 22, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33678.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

5. 
   maflcko commented at 1:41 pm on October 22, 2025: member

   Not sure. This seems to be partially reverting e56fc7ce6a92eae7e80657d9f57a148cc002358d. See also #31215 (review)
6. 
   furszy commented at 2:32 pm on October 22, 2025: member

   Not sure. This seems to be partially reverting e56fc7c. See also #31215 (comment)

   The default value is kept unless the system has fewer cores. I think it makes sense to not exceed that number, as having more threads than cores doesn’t really help.

7. 
   furszy commented at 2:35 pm on October 22, 2025: member

   Answered without reading #31215 (review), interesting. Maybe having more is good but probably not 16 fixed? Like a factor of 2 of the number of cores seems better to me.

   Or well.. that is ok for small end device but that would spawn way more threads in bigger ones. I’m not sure anymore either.

8. furszy closed this on Oct 22, 2025

   ---

9. 
   andrewtoth commented at 2:51 pm on October 22, 2025: contributor

   I think it makes sense to not exceed that number, as having more threads than cores doesn’t really help.

   This would make sense if RPCs are purely CPU bound. Many RPCs are mainly IO bound, and the OS can suspend a thread while it waits on IO. Absent coroutines that can suspend execution on the same thread for IO, more threads than cores will be a benefit.

10. 
    andrewtoth commented at 2:58 pm on October 22, 2025: contributor

    Would it make sense to lower the default only on 32-bit systems? We have lower maximum settings for dbcache and maxmempool on these systems as well, since they are more memory constrained.

    This concern was raised here as well #31215 (comment).

Contributors
furszy DrahtBot maflcko andrewtoth

Labels
RPC/REST/ZMQ