MySQL y los pools de Threads

Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.

Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.

Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.

Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.

Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.

Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:

1 - MySQL utilizado como base de datos NoSQL en memoria SSD
2 - Percona como alternativa a Oracle tras el lio de los precios con InnoDB