Ajustando la cache de consultas de MySQL para un mejor rendimiento de Drupal

¡Hola de nuevo! Después de un tiempo de inactividad voy a retomar el blog, aunque no prometo publicar muy asiduamente :-P

Continuando el hilo post anterior (mayo de 2010, ¡la de cosas que han pasado desde entonces!), vamos a ver cómo aumentar el rendimiento de un sitio Drupal, en este caso a través de la cache de consultas de MySQL.

En /admin/reports/status/sql, Drupal muestra algunas estadísticas interesantes del servidor MySQL, que nos dan pistas sobre lo bien o mal optimizado que tenemos el sistema: número de consultas cacheadas, ordenaciones sin índices, etc.

En la explicación de alguno de los indicadores se indica “debe ser cero”. Estos indicadores son Select_full_join, Select_range_check y Sort_scan. En términos generales, si estos valores son altos se debería modificar el esquema de la BD añadiendo índices, aunque si estamos hablando de Drupal esta situación no debería darse, ya que el esquema tiene índices correctamente establecidos.

Otro indicador interesante es Qcache_lowmem_prunes. Indica “el número de veces que MySQL tuvo que retirar consultas del caché porque se quedó sin memoria”. En mi caso, este indicador mostraba el alarmante valor de 349102 (¡desde que se arrancó el servidor!).

Para arreglar esta situación vamos a aumentar el tamaño asignado a la caché de consultas. Lo haremos desde el fichero de configuración de MySQL (my.cnf):

query_cache_limit = 1M
query_cache_size = 32M

El primer parámetro es el tamaño máximo de las consultas “cacheables”. Lo usaremos para evitar cachear consultas lentas o muy grandes, que suelen ser infrecuentes (y por tanto no tiene mucho sentido cachearlas).

El segundo parámetro es la cantidad de memoria que queremos asignar a la caché. Cuanta más memoria RAM tenga nuestro servidor, mayor valor podremos darle. En mi caso el servidor tiene 512MB, de los cuales alrededor de 200 están ocupados por el sistema y los servicios (Apache, el propio MySQL, memcache y los servicios de correo). Así que puedo aumentar el tamaño del cache hasta 50MB.

Después de reiniciar el servidor, lleva 95 días funcionando y arroja un valor de 3451 purgas. Muchas menos que con la anterior configuración.

Esta es una medida sencilla que ayuda a optimizar la cache de consultas de MySQL, un sistema que impacta en el rendimiento global del sistema, sobre todo si no tienes un sistema de caché fuera de MySQL.

Mejor rendimiento de Drupal con GraphicsMagick

Un pequeño (y espero útil) apunte antes de que penséis que he abandonado completamente el blog :-(

Se trata de un consejo para mejorar el rendimiento de nuestro sitio Drupal. El sistema utiliza por defecto la biblioteca GD para manipular imágenes (por ejemplo, generar miniaturas). El módulo ImageAPI inserta una capa de abstracción en Drupal que permite elegir qué biblioteca gráfica usar, GD o ImageMagick. Es mejor utilizar ImageMagick, ya que es una biblioteca independiente de PHP y, por ello obtendremos mejor rendimiento total en Drupal, y además es más estable (si falla GD puede caer todo el motor de PHP, sin embargo, si falla ImageMagick no caerá, ya que es un binario diferente).

Pero aún mejor: existe un proyecto llamado GraphicsMagick, que es un fork de ImageMagick y que es más estable y, sobre todo, con mejor rendimiento, ya que consume menos memoria y es más rápida. Y lo que es mejor, tiene la misma API que ImageMagick (el comando

convert), con lo cual podemos engañar a ImageAPI diciéndole que use ImageMagick cuando en realidad tenemos instalado GraphicsMagick.

Para lograr esto no tienes más que instalar GraphicsMagick y el módulo ImageAPI de Drupal, en dos sencillos pasos. Supongamos que trabajamos con un servidor Debian/Ubuntu (en otros sistemas operativos no debería ser muy diferente):

  1. Instalamos GraphicsMagick:
    apt-get install graphicsmagick-imagemagick-compatPodemos probar que GraphicsMagick funciona escribiendo convert en la consola:

isra@salon:~$ convert
GraphicsMagick 1.3.5 2009-01-26 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2009 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Usage: convert [options ...] file [ [options ...] file …] [options ...] file

[más opciones]

  • Instalamos el módulo ImageAPI y lo activamos en /admin/build/modules (módulos ImageAPI e ImageAPI ImageMagick).
  • Accedemos a la configuración de ImageAPI en Administración > Configuración del sitio > ImageAPI (/admin/settings/imageapi) y veremos el siguiente mensaje: “The ImageAPI ImageMagick module is the only enabled image toolkit. Drupal will use it for resizing, cropping and other image manipulations“.
  • Si también hemos activado el módulo ImageAPI GD2, nos dará a elegir (seleccionamos ImageAPI ImageMagick como opción por defecto):

¡Y listo! Fácil y rápido. Podemos comprobar que funciona accediendo a Administración > Configuración del sitio > ImageAPI > Configurar (/admin/settings/imageapi/config), lo que nos mostrará información sobre GraphicsMagick (versión, tipos soportados, etc):

¿He hecho benchmarks para comprobar la ganancia de rendimiento con respecto a ImageMagick?

Pues no, lo siento. Pero los chicos de GraphicsMagick sí los han hecho, y son bastante jugosos.

Pero… ¿no es necesaria la extension imagick de PHP?

No, no es necesaria, ya que ImageAPI interactúa con ImageMagick/GraphicsMagick a través del binario
convert

Iré escribiendo algunos artículos más sobre técnicas fáciles para optimizar el rendimiento de Drupal.

Los CMS más populares

El ritmo de publicación del blog está algo bajo últimamente, y seguirá así en las próximas semanas ya que estoy bastante ocupado con diversos proyectos, alguno de los cuales contaremos en detalle ;-)

No obstante, me gustaría comentar el informe de CMS Wire sobre los gestores de contenido más en boga en este año 2009, que el creador de Drupal ha comentado con gran acierto. Las encuestas arrojan unos resultados esperables pero muy interesantes.

En primer lugar, la ya tradicional hegemonía de PHP como tecnología más popular para gestión de contenidos. Me sorprende que, en la era de los frameworks no tengan tanta fuerza otras tecnologías como Python con Zope o Django (a excepción de Plone), aunque quitarle el puesto al “trío de ases” es tarea difícil, por el recorrido y la comunidad que tienen.

Los CMS más populares no son necesariamente los mejores

En segundo lugar, es muy importante notar que el estudio no es un ránking de los mejores CMS, sino de aquellos más populares, con los que más familiarizados están los encuestados. Que WordPress y Joomla sean los más populares no significa que sean los mejores. Tienen grandes bazas como el apoyo de la comunidad, mucha documentación, gran cantidad de plug-in y muy buena aceptación en entornos empresariales.

Pero no nos equivoquemos. WordPress juega en una liga distinta a Plone y Drupal. WordPress es un gestor de blogs, fácilmente personalizable y puede ser utilizado y administrado por gente con muy pocos conocimientos. Sin embargo, no debe ser empleado como gestor de portales o grandes sitios. Tampoco como sistema ECM ni Intranet. Además, las “tripas” de WordPress tienen mucho código spaghetti. No obstante, mi experiencia personal (lo estoy utilizando para dos proyectos, una revista on-line y una web corporativa) es muy positiva, ya que en muy poco tiempo pude montar un pequeño sitio web y estoy bastante satisfecho, especialmente con la API para crear themes.

Un último apunte sobre WordPress: la métrica de popularidad de WordPress está ligeramente inflada ya que muchos de los encuestados confundieron el gestor de contenidos WordPress con el servicio de alojamiento gratuito WordPress.com.

Por su parte, Joomla es un portal bastante ampliable (hay plug-ins para hacer CRM y cosas así), además es fácil de usar para editores y administradores. Pero en mi opinión, no puede crecer a sitios realmente grandes.

Valoración general de los CMS más populares

En otro nivel están Drupal y Plone. Ambos presentan no sólo una solución de gestión de contenidos, sino un framework para desarrollar sistemas de este tipo (Drupal en sí mismo y CMF, que originalmente no forma parte del proyecto Plone), con lo cual la capacidad para ampliar estos CMS es mucho más grande, sobre todo en Plone por estar construido sobre Zope.

En tercer lugar, la gente está entendiendo que el concepto de CMS es demasiado genérico. No se puede comparar Alfresco, que es un ECM, con un gestor de tareas colaborativo o una red social. Todos ellos son gestores de contenido pero es necesario no confundir peras con manzanas. A las PYMES les suelen interesar los gestores de publicación de contenidos, tales como portales, prensa, blogs… soluciones sencillas que permitan crear rápidamente sitios con un diseño propio y contenidos adecuados. Y a organizaciones más grandes, sistemas que puedan crecer hacia la gestión documental (ECM), intranets/portales del empleado o aplicaciones empresariales más grandes.

Otras conclusiones interesantes:

  • En la valoración general, Joomla! desciende por debajo Alfresco y Silverstripe. También sale mal parado Plone, en noveno puesto con sólo un 30% de votos positivos. El otro 70% son los que no fueron suficientemente hombres para plantarle cara a Zope ;-)
  • Drupal es el que más ha crecido en cuanto a profesionales del desarrollo, y WordPress en cuanto a márketing/redaccción. Además, hay casi el triple de libros sobre Drupal (25) que sobre WordPress (9). Sobre Plone, hay 7 libros publicados.
  • En general, en Internet se habla mucho más de Joomla que de Drupal. Este dato se invierte en los medios sociales, sobre todo en Twitter.
  • Este año, en los blogs (Technorati) se habló de Plone un 55% menos que el año pasado. No obstante, Plone es el cuarto CMS en cuanto a repercusión en la web social.
  • Drupal tiene tantos premios como WordPress y Joomla juntos.

Una última cosa… me alegro de que hayan eliminado del top 20 a PHP-Nuke, que lleva bastante tiempo sin publicar una nueva versión. Antaño fue un sistema omnipresente —diría incluso que marcó una generación— pero malísimo en cuanto a seguridad, diseño, calidad del código, etc. Hoy en día la gestión de contenidos es diferente… gracias a Dios.

Drupal 7 será el CMS semántico

Sólo una pequeña nota para informar de lo que he leído en Sitepoint sobre la nueva versión de Drupal. Si hasta ahora era de los mejores CMS (sus premios le avalan), compitiendo directamente con el “monstruo” Plone, con este movimiento, y si todo sale bien creo que se convertirá en el súper-CMS del presente y el futuro (perdona que me ponga en plan gurú-profeta amarillista).

La idea es darle a Drupal la forma necesaria para convertirse en un nodo de la web semántica, perfectamente interconectado por Web Services, REST o HTTP sin más, que sea capaz de tomar y servir información de otros nodos, permitiendo a los usuarios localizar información dentro y fuera del sitio web. Lo que no sé todavía es si el almacenamiento se mantendrá como hasta ahora, en una base de datos relacional, o por el contrario pasarán a usar una base de datos semántica. Si se diera el primer caso (y así parece, según los avances de Carlos Rincón), deberían utilizar una especie de ORM para mapear las descripciones en la BD, y seguramente esa capa fuese reutilizable más allá de Drupal (como pasó con su motor de plantillas).

Drupal pasa dejando huella, haciendo avanzar el ecosistema de programación PHP y la web en general. Gracias y felicidades, Drupal.

PD: la imagen está alojada por Facebook Inc., hosting gratuito de imágenes. Gracias a su falta de privacidad me voy a ahorrar unos eurillos…