Blog de Linube

Generalmente, se suele decir que un CMS tiene una mala gestión de consultas sobre la base de datos, que abusa de ellas o que hace chapuzas. Soluciones en WordPress que, a veces, pueden ser ciertas. Pero esas afirmaciones también pueden radicar en un desconocimiento técnico sobre cómo funciona realmente la herramienta y qué cuidados requiere.

Hace algunos días se formó un interesante debate en torno a un post en Loogic. En él se hablaba de la problemática de tener cuello de botella en el backend de base de datos de una aplicación web. Desde nuestra experiencia podemos decir que no es tanto culpa de la base de datos, sino de la programación en la aplicación. También puede ser consecuencia de una mala o desatendida gestión en la base de datos y configuración del servidor.

La base de datos de WordPress

Podemos ahorrarnos muchas consultas a la base de datos desde WordPress, evitando el uso de Template Tags (funciones que ayudan a crear themes) o plugins que pueden hacerse desde su core. Además, puede ser totalmente ineficaz si no tenemos especial cuidado en la gestión de la base de datos. Deshabilitar el motor innodb o los logs pueden ahorrarnos mucha carga en el servidor. Pero no nos libra de tener que hacer una optimización en los valores de query_cache, por ejemplo.

Es importante también prestar especial atención en la actualización del propio CMS. Algo que puede efectuar cambios en el esquema de base de datos y mantener funcionalidades obsoletas, especialmente con plugins o funciones que se sigan usando. Plugins como WP SuperCache, basado en WP Cache 2 de Gallir, reducen los accesos de datos a MySQL. Pero en algunos casos se han encontrado problemas que venían arrastrándose desde versiones atrás.

El problema de los plugins

En un caso concreto nos hemos peleado con algún WordPress que hacía consultas antes de lanzar la acción init, que es la acción que activa plugins como WP SuperCache. Esto hacía ineficaz toda posibilidad de cacheo a través de plugins. Podríamos evitar esta situación cacheando todo el sitio en archivos estáticos HTML, a través de módulos memcached o en el servidor web, usando sistemas de proxy caché tipo Squid.

Este tipo de cosas hay que hacerlas después de asegurarse de que la aplicación web está optimizada. O al menos no abusa demasiado de la base de datos. Más que nada porque este tipo de soluciones conllevan una serie de costes asociados. Por ejemplo, si optamos por cachear todo a disco necesitaremos, en sitios web con medio o alto tráfico, disco SAS a 10k o 15k revoluciones. Para así evitar los cuellos de botella que tendríamos con discos SATA. Muchos proveedores venden esto como «un servidor más grande», nosotros preferimos abordarlo de otra forma.

Hay otras situaciones en las que un solo plugin puede ser el culpable de problemas de rendimiento. Muchas veces se confía demasiado en el buen hacer de los desarrolladores de plugins muy utilizados como el All In One Seo Pack, que resulta no ser tan óptimo como cabría esperar.

Nuestro trabajo

Empezamos por hacer un diagnóstico de la aplicación web. Si se trata de WordPress, limpiamos el theme y los plugins desactualizados. Además de comprobar el estado de la base de datos y desarrollar plugins o themes que utilicen la última versión de la API. Si fuese necesario, también buscaríamos soluciones en cuanto a sistema que mejoren el rendimiento de la aplicación.

Estas soluciones van desde realizar optimizaciones del servidor web o en la base de datos; a implantar soluciones de caché en memoria, como opcode caché para PHP. Así como distribuir el contenido estático del blog entre varios servidores o servicios de terceros. Para soluciones más avanzadas o sitios web de gran cantidad de datos y tráfico es mejor optar por servidores cloud.

Soluciones en WordPress

No siempre una solución puede ser la cura a todas las enfermedades. Por ejemplo, un tipo de motor de almacenamiento en MySQL frente a otro, como myisam frente a innodb, es más rápido en lectura. Pero esto no siempre es así. También se pueden ver casos como que una solución memcached proporciona menos rendimiento que otro servidor de base de datos. O que cachear en disco penalice mucho más que almacenar en la base de datos. No se pueden tratar todos los problemas por igual en casos de rendimiento web.

Hemos tenido alguna experiencia con clientes que, teniendo un servidor dedicado saturado, se han pasado a un servidor cloud. Así, con solo algunos cambios en el CMS, se han ahorrado bastante dinero al mes en hardware.