Sobre el caché de Gesbit lo único que se puede decir es que no existe aún. Bueno. No. En realidad se pueden decir también otras cosas, sino para qué me iba a poner a escribir esta entrada sobre el caché de Gesbit. Se puede decir que cada vez lo veo más útil, hasta el punto de haber hecho ya algún que otro intento de implementación, si se puede decir así. Iba a decir necesario en lugar de útil sólo, pero, lo cierto es que Gesbit, hasta donde yo llego, no es "pesado", y un sistema de caché vendría a ser un "por si acaso", pensando en que Gesbit gestionara bitácoras con "muchas visitas".
Como los que seguís esta bitácora ya sabéis, la portada de una bitácora en Gesbit necesita realizar sólo (creo que puedo decirlo así) 12 consultas SQL a la base de datos. Además, la mayoría de ellas son bastante sencillas, que incluso ni requieren datos. Sin embargo, un sistema de caché evitaría todavía más consultas SQL, y, en el caso de bitácoras con muchas, no sé cuántas, pero, muchas visitas, no es que piense que Gesbit vaya a ir mal, pero, un sistema de caché ayudaría al servidor, sería bien. Como ya he dicho, he hecho varios intentos, y, escribo esto por si se me ocurre algo.
Hoy he puesto en orden el archivo "gb-globals.php", donde se "inicializan" las principales "variables globales" de Gesbit. Lo he hecho pensando en que el caché de Gesbit se implementase por medio de un plugin, no desde el propio "corazón" de Gesbit. Y tengo algunas, muchas dudas. El archivo que he mencionado procura guardar cierto orden en la inicialización de las variables, de tal modo, que, cuando se inicializa la variable "GbPlugins" (el gestor de plugins de Gesbit) tan sólo se han realizado dos consultas SQL a la base de datos. ¿Por qué veo estas dos consultas necesarias?
Bien. La idea es la siguiente. Para actuar, para ponerse en marcha, un plugin necesita "estar activo". Una de las dos consultas, por lo tanto, es la que requiere las opciones "auto cargables" de Gesbit, y entre estas se encuentra la que especifica qué plugins están activos. La otra consulta no retorna datos: se trata de establecer en la base de datos el "charset" que se utilizará. Estas dos consultas SQL son necesarias, tal como lo veo ahora. Podría pensarse entonces qué sentido tiene el sistema de caché implementado de este modo, si, de todas formas, va a requerir consultas a la base de datos, aunque sean sólo dos.
Pero, creo que mi razonamiento no falla, dicho de otro modo, si me pregunto, ¿el plugin que implemente el sistema de caché tiene o no tiene que saber si está activo o no? Es evidente que sí. Luego, entonces, no hay más que hablar, es necesaria la consulta SQL correspondiente. Ahora bien, queda otra posibilidad: que sea el propio Gesbit quien implemente un sistema de caché. ¿Sería necesario en este caso recurrir a la base de datos? No. Puesto que Gesbit, antes de hacerlo, podría poner en marcha el sistema de caché, que comprobaría si existe el contenido que se solicita, y servirlo, directamente, sin más ni más.
Creo que hay que valorar, entonces, esta cuestión. Yo quisiera un sistema de caché que no requiera de la base de datos para funcionar. Luego entonces este sistema no podría implementarlo un plugin, si el funcionamiento de este necesita de al menos dos consultas SQL a la base de datos. Pero integrar el sistema de caché en el propio Gesbit, aunque no me parece mal, de entrada, implica una serie de cuestiones. Por ejemplo, habría que especificar el directorio donde guardar el contenido mediante alguna constante: puesto que se trata de evitar el trato con la base de datos. Y luego estarían los correspondientes permisos...
Permisos que tendría que tener Gesbit para escribir en el directorio susomentado, manteniendo hasta ahora en Gesbit la especie de norma de que este no requiera permisos de escritura en ningún directorio del servidor. Pero está claro que algo habría que sacrificar y si es menester contar con permisos en un directorio, para guardar el contenido en "caché", así será, una excepción a la regla. Al escribir esto estoy dándole vueltas al coco, y veo atractiva la posibilidad de que Gesbit implemente de suyo un sistema de caché. Ya iremos viendo en qué queda todo este asunto.
Publicada el Miércoles, 25/6/2008 por David Esperalta
Suscribirse a esta entrada - URL para Trackbacks
Despues de leer, ayer, tu interesante comentario sobre el coste de las páginas, le puse un "cronometro" a mi gestor para ver cuanto tardan en generarse, y en local, con XAMMP en Win XP, tardan de orden de entre 100-300 milisegundos, según tengam mas o menos contenido. Despues, con la web subida en internet me ha sorprendido que el tiempo de generación bajaba a una media de 30 milisegundos. Tambien le puse un contador de consultas SQL, a ver cuantas hacía, y sorpresa: mas de 20 por página, a veces incluso 40. Pero lo he dejado en una media de 7 despues de tocar un poco el código. No me habría dado cuanta si no llego a leer tu artículo. Lo de los 30 milisegundos, ha sido despues de arreglar lo de las consultas.
Asi que gracias otra vez!!
Pues me alegro de que lo dicho te sirviera de algo Julián. ;) Por cierto, por si te sirve de algo, yo también noto mejoría cuando Gesbit corre en el servidor, y no en mi máquina, pero, lo achaco a que mi máquina es más bien viejita, y, en cambio, el servidor debe ser un maquinón de órdago. Así es normal que vaya más rápido. ¿No? :)