Redundancia: cache de base de datos (WordPress, plugin y MySQL)

Desde hace unos días vengo analizando como la configuración de este blog con WordPress termina creando distintas cache de las consultas realizadas a la base de datos, casi de manera innecesaria.

El escenario

WordPress cuenta con un sistema de cache incluido, no obstante muchos de sus usuarios, entre los que me incluyo, prefieren utilizar un plugin para optimizar el consumo de recursos de la plataforma. En mi caso, y desde hace tiempo, utilizo W3 Total Cache, uno de los plugins más completos y con potencial a la hora de personalizar una configuración.

Por otro lado todos sabemos que MySQL es el motor de base de datos que eligieron desde WordPress para guardar toda la información generada por nuestras bitácoras. Un motor al que le tengo mucho cariño y sobretodo confianza.

Entonces a lo que respecta a la base de datos tenemos 3 caches distintas: la de MySQL, la de la consulta del W3tc y la estática final que es de disco y que previene la acción de generar nuevamente todo el contenido de manera dinámica.

wordpress y MySQL

Cache MySQL

Muchos de los que tenemos acceso a la configuración de MySQL de nuestro servidor tenemos activada la capacidad del motor de datos para generar una cache automática.

Para el que no lo sabia, MySQL tiene la opción de generar una cache en memoria de las consultas realizadas, cada vez que realizamos una consulta del tipo SELECT, MySQL almacena el texto junto al resultado que se le envió al cliente. Posteriormente si MySQL recibe una cadena idéntica el servidor se encarga de devolver el resultado almacenado anteriormente.

Este cache es muy efectiva en entornos donde las tablas no cambian mucho y el servidor recibe muchas consultas idénticas.

Para más tranquilidad cuando las tablas son modificadas cualquier entrada almacenada en el cache de MySQL es eliminada, garantizando que se muestren resultados incorrectos.

Cache MySQL (W3 Total Cache)

w3 total cache

El plugin de WordPress que elegí y que para muchos usuarios de WordPress es uno de los mejores, cuenta con la capacidad de crear cache de los resultados de la base de datos. Cuando elegimos activar esta opción tenemos varias opciones para decidir guardar esta información:

  • MemCached: La información se guarda en memoria RAM.
  • Disco: Los datos se guardan directamente en el disco rígido de nuestro servidor.
  • OpCode: La información se guarda también en memoria RAM.

Prefiero guardar la información en memoria RAM. Este decisión siempre se ve afectada por la cantidad de memoria disponible en nuestro servidor, en mi caso decidí utilizar la memoria que tengo disponible, además es mucho más rápida que utilizar el disco.

La cache de MySQL merece un post propio. Pero para resumir se puede configurar de distintas maneras, la más común es la que crea una cache de todas las consultas del tipo SELECT de forma automática sin requerir que el programador exprese si desea almacenar o no la consulta.

Cache de disco

Finalmente tenemos la cache de disco que genera cualquier plugin optimizador de WordPress, esta opera guardando una versión estática de nuestros post, categorías, etc. En pocas palabras una pagina que se generó de manera dinámica se guarda en un archivo en el disco para posteriormente evitar tener que realizar todas las consultas nuevamente.

Entonces tenemos 3 caches distintas para guardar la información generada por MySQL.

Cache de Mysql -> W3 Total Cache (MySQL) -> Cache Disco

¿No es demasiado redundante esto?

Un caso en concreto

Vamos a suponer que 2 personas visitan la misma entrada de un blog WordPress con esta configuración que planteo.

La primer persona:

  • Mysql realiza todas las consultas SELECT para mostrar la información y las guarda en su cache interna. Además devuelve los resultados a WordPress para que desde PHP se manipule esa información para mostrar la entrada.
  • W3 Total Cache. Guarda la consulta a la base de datos mediante alguno de los mecanismos disponibles (memcached, APC, Disco).
  • W3 Total Cache. Genera un archivo estático del post.

Segunda persona:

  • W3 Total Cache muestra el archivo estático generado en la consulta anterior.

Todo este proceso ocurre siempre que W3tc no detecte que el archivo fue modificado o su tiempo de vida sobrepaso el limite y deba regenerarse. Sino el proceso se reinicia desde el primer paso, también con sus respectivas comprobaciones.

La cache de disco del paso final, si bien es la más lenta, es la termina ahorrando más recursos.

El principal problema es que la cache de MySQL y la de W3 Total Cache de la base de datos contienen prácticamente la misma información, cosa que no es grave salvo que tengamos problemas relacionados al consumo de memoria RAM de nuestro servidor.

Conclusión

mysql cache uso de memoria

Para suerte de todos nosotros todo esto se puede puede configurar.

En mi caso hice la prueba de desactivar la cache de MySQL, ahorrando todo ese consumo de RAM y el rendimiento no mermo, al menos no de forma apreciable. También probé el caso inverso, es decir, deje activada la Cache de MySQL y desactive la cache de base de datos del W3tc. Lo mismo ocurrió, no puede notar diferencias en el rendimiento del sitio.

Como conclusión les recomiendo activar una cache o la otra, pero no las dos, salvo que el consumo de memoria RAM no sea un problema.

Categorizado en: