Me apetece escribir sobre el funcionamiento del sistema de caché en Gesbit. Ni siquiera tengo claro que vaya a formar parte de Gesbit, seguimos haciendo pruebas (enlace probablemente temporal), y haciendo cambios a la clase "GbCache", que es la encargada de realizar prácticamente todo el trabajo necesario. ¿Cómo funciona el caché de Gesbit? Voy a tratar de explicarlo en esta entrada, continuación de esta y esta otra.

De entre todos los intentos de implementación, sin duda este último es en el que he llegado más lejos, y el que mejor ha salido de todos. En primer lugar hay que decir que Gesbit no delega el caché de contenido a un posible plugin. ¿Por qué razón? Porque inicializar el sistema de plugins de Gesbit tiene un coste: una consulta SQL a la base de datos, y además sería necesaria la ejecución de más código PHP del verdaderamente necesario.

Dejando a Gesbit encargado del caché conseguimos varias cosas, por lo tanto. En primer lugar, la clase "GbCache" se instancia acto seguido de las clases "Timer", "Input" y "Localize" (esta última podría evitarse, si se viera necesario). En ese punto Gesbit no ha hecho ni una sola consulta SQL a la base de datos, y la clase "GbCache" ya puede hacer su trabajo, uno de ellos: servir contenido previamente "cacheado".

En ese punto, como digo, Gesbit tampoco ha necesitado instanciar otras clases, como "GbDb", "User", "GbPlugins", "GbOptions", "DateUtils" o "Themes". De modo que no sólo nos ahorramos consultas SQL a la base de datos, sino que además nos ahorramos no poco del código PHP necesario para la inicialización y puesta en marcha de Gesbit. La clase "GbCache" se encarga de todo, de guardar contenido en caché y de recuperarlo.

¿Qué es lo que se guarda en el caché de contenido? Gesbit puede guardar en el caché de contenido todo el XHTML y el RSS que produce. La portada de la bitácora, la páginas de categorías, etiquetas o autores, el archivo, las entradas "solas", las páginas de la bitácora, eso en lo que respecta al XHTML, pero, Gesbit también guarda en el caché el RSS de todos los "feeds" que puede generar en una bitácora determinada.

La verdad es que ha sido muy interesante trabajar en la clase "GbCache". Y es que resulta curioso cómo funciona. Por ejemplo, podría pensarse que todos los usuarios reciben el mismo contenido "cacheado", pero, lo cierto es que Gesbit tiene en cuenta cierta información "única" para cada usuario, "cachea" el contenido, y se lo sirve a ese mismo usuario, y no a otro que no corresponde. Esta información se basa en ciertas "cookies" de Gesbit, y en la URL de la petición del usuario.

Obviamente, no se trata de que siempre sea de este modo. Si tú visitas una bitácora por primera vez, no eres un usuario registrado, y nunca has dejado un comentario en la misma, tú no tendrás "cookies" de Gesbit en tu navegador. Si yo estoy en tu misma situación y visito la bitácora, recibiré el contenido "cacheado" que en realidad se generó para ti: como ambos estamos en igual situación, tu contenido sirve para mí perfectamente.

Otra curiosidad se da en el nombre de los archivos que guardan el contenido "cacheado", que no está ni mucho menos elegido al azar. Todos los archivos tienen la misma longitud: 21 caracteres, puesto que no todos los sistemas en que pueda funcionar Gesbit permitirán cualquier número de caracteres como nombres de archivos. El nombre se divide en dos partes separadas por un "guión", aunque esto último daría igual que no fuera así.

Ambas partes del archivo son en realidad parte de un "hash" único, en teoría. Así se consigue que el nombre del archivo nunca supere una cantidad máxima de caracteres: 10 por cada hash y 1 del guión, igual, 21 caracteres, en todo caso. La primera parte del archivo es un identificador de contenido, por decirlo así, "file token", como lo llamo en el código fuente de Gesbit. Supongamos que Gesbit va a "cachear" una entrada, cuyo título es "¡Hola mundo!", la primera parte del archivo podría ser esta:

single-hola-mundo

Estoy tiene una función, y es que, de esa entrada, podemos "cachear" su "feed", de modo que la primera parte del nombre del archivo quedaría así en ese caso:

single-hola-mundo-rss

De ese modo, si se actualiza o se borra de la bitácora la entrada en cuestión, nosotros sabremos localizar y borrar no sólo el archivo que comience por "single-hola-mundo", sino también el archivo que comience por "single-hola-mundo-rss", puesto que ambos guardarían contenido "obsoleto", desde el momento en que se actualizó o borró la entrada. Más de lo mismo ocurre para el resto del contenido: se sigue el mismo patrón para etiquetas, entradas, autores, etc.

tag-neil-young
 
tag-neil-young-rss
 
category-musica
 
category-musica-rss
 
autor-admin

El contenido más general, como pueda ser la portada de una bitácora, y las distintas páginas de entradas (de más recientes a más antiguas), así como los "feeds" "generales", también tiene su propia "primera parte" en el nombre del correspondiente archivo. En este caso el identificador es "index", simplemente. De este modo, podemos borrar todos los índices, en caso de que se borre una entrada, pero, sin necesidad de borrar del caché el resto de entradas, etiquetas, categorías, etc.

Eso en lo que respecta a la primera parte del archivo, que, como hemos dicho, tampoco se guarda "tal cual", sino que a partir del identificador se consigue un "hash" único, de 10 caracteres, que es lo que en realidad formará parte del archivo. Ahora, sin querer ser pesado, toca hablar de la segunda parte del archivo. Esta es más sencilla de obtener, puesto que, como ya he mencionado, se basa en información guardada en un par de "cookies", y en la propia URL que esté procesándose.

El valor de las "cookies" y la URL conforman un identificador único, no porque nosotros lo necesitemos, quiero decir, para localizar contenido en el caché para su borrado, por ejemplo, sino que este identificador único está dispuesto para seguir a usuarios únicos, a lectores únicos de la bitácora. Como mencioné más arriba, varias personas pueden ser, para los efectos del caché de contenido en Gesbit, únicas.

En definitiva, una misma URL, y unos mismos valores en las "cookies" (o ningún valor), conformarán una segunda parte del archivo única, pero, que, puede servir para varias personas, justamente, las que visitan la misma URL, y tienen los mismos valores (o ningún valor) en las "cookies" necesarias. De esta "cadena" formada con la URL y el valor de las "cookies", obtenemos un "hash" de 10 caracteres, que formarán parte del nombre del archivo, como queda dicho.

Sobre el caché de contenido cabría añadir que este se guarda "comprimido", aunque esto supone el coste de la "descompresión", a la hora de recuperar el contenido "cacheado". Sin embargo, creo que merece la pena: el rendimiento es muy rápido, y, en lugar de guardar y leer archivos de hasta 50 KB, lo que guardamos y leemos son archivos de 3, 6, 16 KB poco más o menos. Y, dicho esto, creo que básicamente terminamos con una parte del trabajo de la clase "GbCache" de Gesbit.

Por otro lado, cabe decir que el caché de contenidos en Gesbit se gestiona "solo", en caso de usarlo. Su uso es opcional y depende únicamente de una constante en el archivo de configuración de Gesbit. Esta constante, de entrada, será una cadena vacía, y, siendo así, la clase "GbCache" entenderá en su momento que no debe realizar su trabajo, que el usuario no precisa el uso del caché de contenidos. Así, bastará que esta constante contenga una cadena para que la clase "GbCache" se ponga en marcha.

Ahora bien, lógicamente, no vale cualquier cadena en la constante de configuración. La propia clase "GbCache" se encargará de comprobar que esa cadena de caracteres contiene la ruta de un directorio válido. Esta ruta puede ser absoluta, o relativa al directorio de instalación de Gesbit. Por directorio de caché válido se entenderá un directorio existente y con los suficientes permisos de escritura.

Por el momento, y puesto que el caché de contenido es opcional además, Gesbit no intentará crear ningún directorio, ni comprobará los permisos de escritura, ni tratará de cambiar los permisos al mismo: si el directorio es válido, Gesbit hará su trabajo, y, si no lo es, advertirá al usuario del problema y de la forma de corregirlo, y hasta le invitará a no usar el sistema de caché, puesto que Gesbit funcionará sin el mismo.

Vale. Supongamos entonces que Gesbit cuenta con un directorio válido, con los suficientes permisos de escritura. Entonces, Gesbit guardará en dicho directorio el caché de contenidos, esto es varios archivos, actualmente, hasta dos horas después de su creación. Efectivamente, el caché de contenidos tiene un "salvavidas", una forma de asegurarse de que el contenido que está ofreciendo Gesbit está actualizado, y es borrando los archivos del caché que superen un determinado tiempo de vida.

El mecanismo de borrado del caché de contenidos "expirado" se pone en marcha al procesar la petición del usuario, es decir, cada vez que tú visitas una bitácora, Gesbit comprobará antes de nada si existe contenido "expirado" en el caché, y lo borrará si así es, de modo que tú mismo ya recibas contenido actualizado, si es menester, y a partir de ti el resto de lectores que visiten la bitácora en cuestión.

Esto último es parte de la magia de todo este asunto. Al menos a mí me parece curioso, qué le voy a hacer. Se trata de que tú, sin saberlo, puedes estar generando el caché de contenido que luego otras personas podrán utilizar después. Y tú también puedes estar sin darte cuenta actualizando el caché de contenido, asegurando que el mismo no contenga datos expirados, ¡y sólo por visitar la bitácora! Te conviertes en una especie de colaborador inconsciente de Gesbit. Y Gesbit te lo agradecerá, puesto que lo mismo que tú haces para otros, otros lo harán para ti.

Por otro lado, que sea Gesbit el que implemente el sistema de caché de contenidos, implica que en varios puntos del mismo ha de entrar en juego la clase "GbCache". Dicho brevemente, cada vez que se borra una entrada, que se actualiza, que se añade una etiqueta, que se edita, una categoría, un enlace, un usuario, se cambian las opciones, se activan o desactivan plugins, se cambia el tema de la bitácora... cada vez que esto ocurre hay que informar a la clase "GbCache".

Me gustaría terminar con algo que comenté en las anteriores entradas en que he tratado más o menos sobre el sistema de caché de contenidos en Gesbit. Y es que este no puede ser perfecto, y, uno de los pasos que he tenido que dar, es concienciarme de esta circunstancia, asumirla, para tratar de llegar a una especie de acuerdo entre lo perfecto y lo verdaderamente posible sin un esfuerzo exagerado y tal vez desproporcionado. El sistema parece funcionar, cumple con su objetivo.

Y el objetivo, puesto que además el caché se "auto actualiza", como he dicho, podría decirse que es el aguantar cierto tirón de visitas en una determinada bitácora. No es un sistema de caché escrupulosamente programado, medido hasta el mínimo detalle, pero, asegurará que, en caso de que una bitácora reciba "de pronto" 1.000 visitas, buena parte del contenido se sirva desde el caché de contenidos, descongestionando el servidor, evitando la base de datos, en fin, como era nuestro deseo.