Las claves del buen rendimiento de Drupal

Drupal es un gestor de contenidos web que nos permite hacer desde sitios básicos hasta complejas aplicaciones web.

Podemos afirmar sin miedo a equivocarnos que el rendimiento de Drupal es bueno. Si navegamos por un sitio desarrollado en Drupal podremos comprobar que la experiencia es óptima y que las páginas cargan a velocidad rápida, evitándonos esa horrible frustración que generan las esperas.

Aquí es donde introducimos el palabro, ya que la clave de todo esto tiene que ver con la caché de Drupal.

Qué es el caché

La caché no es otra cosa que una memoria de acceso rápido, de la que el sistema obtiene la información a una velocidad de vértigo, sin procesamiento previo.

Se usa en innumerables aplicaciones para acelerar el funcionamiento de los sitios web, y de otro tipo de aplicaciones, como por ejemplo apps móviles o programas de escritorio.

Digamos que cuando pedimos una página Web, esta debe ser generada y procesada por el servidor para luego enviarla de vuelta al usuario y que podamos interactuar con ella. Esto tiene un impacto en el servidor que aloja la página web, ya que tiene que realizar un proceso de trabajo. Pero si una vez realizado el trabajo el servidor guarda el producto resultante en una memoria de acceso muy rápido, después puede entregar ese producto en peticiones similares, sin tener que volver a procesarlo.

Hemos ganado velocidad para el usuario, y nos hemos ahorrado un trabajo al servidor, que puede invertir sus esfuerzos en otras tareas. Estamos hablando de la magia de la memoria caché.

Cómo cachea Drupal

Drupal tiene dos modos diferentes de generar los contenidos a almacenar en la memoria caché. Esto depende de si las páginas que va a servir son públicas y por ella navegan usuarios sin identificar o anónimos, o si las páginas requieren de una identificación previa.

Veamos cómo lo hace Drupal en función de esto.

Páginas públicas

Las páginas públicas son siempre iguales para todos los usuarios. Eso facilita mucho las cosas, porque Drupal puede almacenar en la memoria caché una página pública generada por la visita de un usuario, y entregarle la misma página a cualquier otro usuario.

Este modo de cacheo de Drupal es el más sencillo, porque es lo que coloquialmente llamaríamos "café para todos".

Páginas privadas

Con las páginas privadas nos encontramos más dificultades.

Requieren una identificación previa del usuario, y al entrar, la página puede variar en función de los permisos del usuario que se ha identificado. Es decir, Drupal no puede entregarle la misma página a un usuario que a otro, por lo que no puede almacenarla en caché del mismo modo que con las páginas públicas.

El caso más evidente de esto lo encontramos con algo tan banal como el nombre de usuario. En muchas páginas Web, cuando te identificas con tu usuario, encuentras en la parte superior un mensajito de bienvenida con tu nombre de usuario o tu nombre personal. Un mensaje del tipo "Bienvenido Fulanito".

Imagina que Drupal almacena en la memoria caché esa página, y después se la sirve a otro usuario llamado "Menganito". Lo que se encontrará Menganito es un banner de "Bienvenido Fulanito", ya que Drupal no habrá procesado el mensaje, simplemente ha entregado el mensaje procesado para el usuario anterior. Esto sería un error tremendo, y no solo podría incurrir en un error en un mensaje, sino también de funcionamiento. Podría darle permisos de un recurso a un usuario que realmente no los tiene, o podría mostrar información personal de un usuario a otro. Un desastre total.

Aquí es donde Drupal incorpora el concepto de contexto. Un contexto es algo que puede variar el almacenamiento en caché de una página. Un ejemplo ya comentado es el usuario. Drupal es capaz de almacenar una página privada en la memoria caché añadiendo variantes de contexto. En este caso, va a hacer un almacenamiento en caché distinto para cada usuario, evitando el problema comentado.

Además, podemos decir que los contextos que usa Drupal tienen jerarquía. Por ejemplo, si no es necesario almacenar en caché por usuario, podemos hacerlo por rol de usuario. Si no tenemos que mostrar el nombre del usuario, podemos entregar la misma página a todos los usuarios que tengan un rol concreto. En una página donde haya un rol redactor y otro rol revisor, tendríamos la misma página cacheada dos veces, una por cada uno de estos roles.

Y por último, una gran característica de la caché de Drupal son las dependencias. Por lo general, Drupal no pone caducidad a su caché (aunque también podría hacerse, pero no está bien visto). Lo que hace Drupal para cada elemento cacheado en la memoria, es añadirle unas etiquetas llamadas tags, que definen de lo que depende ese elemento. Por ejemplo, ante la situación de que hay una página que hemos almacenado en la caché, y le hemos puesto la dependencia de un usuario porque contiene sus datos personales, Drupal no va a volver a regenerar esa página hasta que el usuario del que depende no cambie sus datos.

Funcionalmente esto se traduce en que cuando el usuario entre a la edición de sus datos personales y los cambie, se produce un proceso que invalida las páginas cacheadas que dependen de esos datos, y los vuelve a generar con los datos correctos.

Dónde cachea Drupal

Drupal usa por defecto la base de datos para almacenar la caché.

Este método es efectivo, pero existen modos más rápidos que pueden ser configurados para el uso de la memoria caché.

Por ejemplo, memcached es una aplicación que se puede instalar en el servidor para almacenar elementos en la memoria RAM. Drupal dispone de un módulo contribuido que puede ser instalado y comunicar con la aplicación memcached, de modo que ya no almacenará la memoria caché en la base de datos, lo hará en la memoria RAM del servidor lo que hará volar el portal Web.

Otra opción es redis. También debe instalarse en el servidor, y Drupal debe instalar el módulo que le permita conectar con la instancia de redis instalada. Redis es una base de datos que almacena objetos, y también es más rápida que la base de datos de Drupal.

Para portales con mucha actividad, se ha comprobado que redis es mejor opción que memcached, pero cuando hablamos de niveles muy altos de actividad.