For this post I’m going to shamelessly exploit the litany of technical problems SimCity players encountered earlier this month and a few examples of how Thread Pool for MySQL and Percona Server for MySQL can help to prevent such incidents.

Users of SimCity, a city-building and urban planning simulation video game, encountered network outages, issues with saving progress and problems connecting to the game’s servers following a new release a couple of weeks ago featuring a new engine allowing for more detailed simulation than previous games. During this same time, we happened to be testing the Thread Pool feature in Percona Server for MySQL, and I saw a connection of how

MariaDB-5.5.21-beta is the first MariaDB release featuring the new thread pool. Oracle offers a commercial thread pool plugin for MySQL Enterprise, but now MariaDB brings a thread pool implementation to the community!

If you are not familiar with the term, please read the Knowledge Base article about it.

The main design goal of the thread pool is to increase the scalability of the MariaDB server with many concurrent connections. In order to test and demonstrate this, I have run the sysbench OLTP RO benchmark with up to 4096 threads to compare the new pool-of-threads and the traditional thread-per-connection scheduler:

We have lately been talking about some upcoming features that we feel are important to MariaDB users, because the corresponding ones that will be provided with MySQL will be incompatible with MariaDB and closed source.

We’re happy to announce the following:

• The next version of MariaDB, version 5.2.10 will include an open source PAM Authentication Plugin. MariaDB 5.2.10 is scheduled for release next week.
• A Windows Authentication Plugin is in development and QA currently and will be part of MariaDB 5.2.11, which is scheduled for release before Christmas.
• MariaDB 5.5 will include both of the above plugins and an open source thread pool implementation. The soon-to-be-launched first version however will not include the thread pool.

Stay tuned for more information

This is the third in a series on what’s seriously limiting MySQL in core use cases (links: part 1, 2, 3). This post is about the way MySQL handles connections, allocating one thread per connection to the server.

MySQL is a single process with multiple threads. Not all databases are architected this way; some have multiple processes that communicate through shared memory or other means. It's cheap to create a connection to MySQL, because it just requires creating a thread (or taking one from a cache). This is generally so fast that