Server
Thread pool
Thread pool is a fixed group of threads that take work from a queue, so the server does not create a new thread for every task. When all are busy, new tasks wait.
How it is measured
Track pool size, active threads, queue length and task wait time. In Node, the libuv pool defaults to 4 threads and handles file system calls, DNS lookups and crypto. `UV_THREADPOOL_SIZE` changes it.
The number to compare is wait time in the queue against task run time. If tasks wait longer than they run, the pool is the bottleneck.
Worked example
A Node service hashes passwords with bcrypt for logins. Each hash takes 90 ms on the libuv pool of 4 threads, so it handles about 44 hashes a second. At a spike of 120 login attempts a second, hashes queue, and file reads on the same pool wait behind them.
Raising UV_THREADPOOL_SIZE to 8 on an 8-core machine doubles the capacity, and limiting login rate keeps the pool free for static file reads.
How it differs
A thread pool reuses threads inside the server for tasks. A connection pool reuses outbound database connections. Thread pool excludes remote resources, connection pool excludes CPU scheduling. A worker thread is a thread you run yourself, and a pool may be built from them. A busy thread pool and an empty connection pool are separate problems.
Common errors
Making the pool much larger than the core count for CPU work. Blocking a pool thread on a slow network call. Using the default 4 for a heavy crypto workload. Sharing one pool between slow and fast jobs. Not measuring queue wait.
In practice
Find which operations use the pool in your runtime, then measure queue wait during your busiest hour. Give slow jobs their own pool so they cannot starve quick ones.