Re: Thread Pool versus Dedicated Threads
"James Kanze" <firstname.lastname@example.org> wrote:
A "thread/process pool model" doesn't mean anything. I'm not
sure what real alternative you're suggesting.
The real alternative is to create a similar message queue design, but =
completely break the relationship of client connections to threads. =
Client connections exist on as many or as few threads as needed by the =
scalibility of the comms library. Requests coming in are packaged and =
posted to a message queue.
A pool of worker threads, proportional to the number of virtual CPUs in =
the server (rather than the number of client connections) pull requests =
from the queue, process the request, and then go back to see if theres =
anything in the queue to process.
This sort of design can ultimately be far better tuned to keep the CPU =
cores as busy as possible, while minimising needless context switches =
from having an "active" thread count far in excess of CPU availability. =
Given a database server that can, likewise, process multiple requests at =
once using asynchronous file io, this design will keep the database =
busy, rather than continually bottlenecking in the single DB "object" =