Interneteando

En los últimos años FreeBSD siempre ha ido a la cola en el rendimiento de MySQL comparándolo con algunos sistemas basados en linux. La mayor diferencia entre uno y otro sistema está en la forma de tratar los threads, pero esto está a punto de cambiar gracias al esfuerzo del equipo de desarrollo de FreeBSD. 

En las versiones actuales (6.2), basta con cambiar la librería de threads utilizada por MySQL para que los resultados sean muy similares a los ofrecidos por una Suse y superiores a los resultados obtenidos por un linux basado en uBuntu. 

Para “obrar el milagro”, basta con agregar un mapeo de las librerías de threads para MySQL a través del archivo /etc/libmap.conf en el que tendremos que introducir estas lineas.
 
[mysqld]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so


Para la versión 7 de FreeBSD aparecerá un nuevo scheduler (ULE 2.0) que mejorará aún mas el rendimiento de MySQL en máquinas con varias CPU y mejorará el rendimiento con respecto a linux.

Kris Kennaway ha publicado un resumen de todo lo que se nos viene encima con FreeBSD 7

Para realizar las pruebas se ha utilizado una tabla en formato MyISAM con 1753184 registros rellenados con datos aleatorios.

Ambos almacenan datos de tipo cadena, la longitud de que ocupa cada caracter suele ser de 1 byte, exceptuando las cadenas “unicode” que pueden llegar a ocupar hasta 3 bytes por caracter. El tamañó máximo para este tipo de campos es de 256 bytes. En los ejemplos me referiré siempre a letras en vez de bytes para hacer más facil su comprensión.

CHAR: Es un tipo de longitud fija, esto quiere decir que el espacio necesario para su almacenamiento es el mismo para una palabra de 5 letras que para una frase de 20.

VARCHAR: Es un campo de longitud dinámica, es decir una palabra de 5 letras, ocupará el espacio de 5 letras más un caracter de fin de cadena.

Casos de uso.

SELECT campo2 from tabla WHERE campo2 = ‘cadena’;
campo2 => VARCHAR(200) => 1,82 segundos sin indexar => 0,00 indexado
campo3 => CHAR(200) => 1,77 segundos sin indexar => 0,00 indexado

SELECT campo2 from tablal where campo2 like ‘%dena%’;
campo2 => VARCHAR(200) => 3,86 segundos sin indexar => 1,75 indexado
campo3 => CHAR(200) => 1,84 segundos sin indexar => 2,19 indexado

Después de estas pruebas, podemos concluir que CHAR se comporta mejor que VARCHAR en campos no indexados, y que VARCHAR es la mejor opción para campos que si soporten indexación.

A la hora de devolver gran número de resultados VARCHAR también se muestra superior sobre CHAR. Un SELECT con 1000000 de resultados tardó en devolver una columna de tipo char 1,24 segundos. La misma columna en formato VARCHAR tan solo tardó 1,06 segundos.

Hoy leía en el blog de Pichongol un interesante artículo sobre la cache que incorpora MySQL y el uso de Memcached para optimizar la carga de sitios web con gran carga de trabajo, pero creo que no está del todo acertado en algunos aspectos.

En su análisis sobre Sistemas intensivos en lecturas vs. Sistemas intensivos en escrituras, pasa por alto un detalle de gran importancia. Las páginas web (que es lo que nos ocupa), son sistemas en los que se acometen muchas lecturas y pocas escrituras por lo que en el 99% de los casos el uso del query cache será beneficioso. Además siempre se pueden utilizar tablas auxiliares para cierto tipo de operaciones de escritura masiva (contadores,estadísticas,sesiones, etc) y utilizar las extensiones de MySQL INSERT DELAYED y INSERT DELAYED … ON DUPLICATE UPDATE para acometer las actualizaciones en estas tablas sin influir en el tiempo de ejecución del script.

Sobre el uso de Memcached, también se pasa por alto un detalle importante, Memcached puede hacer persistir objetos en memoria para distintas máquinas a lo largo de una red y de esta forma varias máquinas se aprovechan del calculo realizado por una. Si hablamos de instalaciones de un solo servidor, el coste de las funciones serialize y unserialize reducen bastante las ventajas de utilizar Memcached.

Por mi experiencia, Memcached es especialmente productivo para entornos de balanceo de carga y funciona especialmente bien en combinación con Lighttpd+FastCGI.