A number of blogs have been written with the intent of describing how
the thread pool manages to solve the requirements of the thread pool.
These blogs are:
MySQL Thread Pool: Problem Definition
MySQL Thread Pool: Scalability Solution
MySQL Thread Pool: Limiting number of concurrent statement executions
Automated benchmark tool for DBT2, Sysbench and flexAsynch
MySQL Thread Pool: Limiting number of concurrent transactions
MySQL Thread Pool: When to use?
MySQL Thread Pool vs. Connection Pool
MySQL Thread Pool: Optimal configuration
MySQL Thread Pool: Benchmarking
There are some interesting discussions in the comments on the scalability solution blog
and on the blog about limiting number of concurrent statement executions
and finally also on the blog about when to use.
These discussions are around when to use it, what other features might be worth
considering and some remarks on the type of benchmarks that could be used to
The requirements we had on the thread pool solution and the solutions were:
1) Split threads into groups individually handled to avoid making the
solution a problem in itself, aim is to manage one active thread per
Connections are put into a thread group at connect time by round robin.
Configurable number of thread groups. This ensures that the thread pool
itself isn't a scalability hog.
2) Wait for execution of a query until the MySQL Server has sufficient
CPU and memory resources to execute it.
Each thread group tries to keep the number of executing queries to one or
zero. If a query is already executing in the thread group, put connection
in wait queue.
3) Prioritize queries on connections that have an ongoing transaction.
Put waiting connections in high priority queue when a transaction is
already started on the connection.
4) Avoid deadlocks when queries are stalled or execute for a long time.
Allow another query to execute when the executing query in the thread
group is declared as stalled (after a configurable time).