"Testing the New Pool-of-Threads Scheduler in MySQL 6.0" is the subject of a Sun blog where timc reports on his investigation into whether the Pool-of-Threads scheduler can provide an operating mode that supports a large number of clients that will be maintaining their connections to the database, without also sending a constant stream of requests to that database.
For this to work, the database has to maintain a (relatively) small pool of worker threads that take a single request from a client, complete the request, return the results, then return to the pool and wait for another request, which can come from any client. The database's internal threads still exist and operate in the same manner, the blogger writes.
Theoretically, he continues, this arrangement should involve less work for the operating system to schedule threads that want CPU, though it should also mean some more overhead for the database, as each worker thread needs to restore the context of a database connection prior to working on each client request.
Furthermore, a smaller pool of threads should also consume less memory, as each thread requires a minimum amount of memory for a thread stack, before the addition of what is needed to store things like a connection context, or working space to process a request, according to the blog.
Mark Callaghan of Google has recently had a look at whether this theory holds true. He has published his results under "
No new global mutexes! (and how to make the thread/connection pool work)". Mark has identified (via the bug he logged) that the overhead for using Pool-of-Threads seems quite large - up to 63%.
The results for timc were quite different. Running sysbench read-only (with the sysbench clients on the same host), he found a loss in throughput of only up to 30%.
Using an additional two test cases (sysbench read-only, with the sysbench client and MySQL database on separate hosts, via a 1 Gb network; and sysbench read-write, via a 1 Gb network). Here, timc found that the impact on throughput is far less significant when the client and server are separated by a network because both introduced network latency as a component of each transaction and the increased amount of work the server and client need to do, e.g., performing ethernet driver, IP and TCP tasks. This, the blogger contends, reduces the relative overhead - in CPU consumed and latency - introduced by pool-of-threads.
"Testing the New Pool-of-Threads Scheduler in MySQL 6.0"
Read More ...