Hace algunos días me resultó interesante el debate que se formó en torno a un post en Loogic, en el cual 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 el que ocurran estos problemas, sino de la programación en la aplicación web o una mala o desatendida gestión en la base de datos y configuración del servidor.
En muchas ocasiones se suele comentar que un cms tiene una muy mala gestión de consultas sobre la base de datos que utiliza, que abusa de ellas o incluso que hace auténticas chapuzas. En algunos casos puede ser cierto, en otros como en el caso de WordPress mayormente esas afirmaciones radican en un desconocimiento técnico en cómo funcionan realmente esta herramienta y qué cuidados requiere las misma.
WordPress
Si bien es cierto que podemos ahorrarnos muchas consultas a la base de datos desde WordPress evitando el uso de algunas de sus Template Tags (funciones que ayudan a crear themes) o plugins que hacen consultas que wordpress ya hace previamente desde su core, esto puede ser totalmente ineficaz si por ejemplo no tenemos especial cuidado en la gestión de la base de datos.
Deshabilitar el motor innodb o los logs del servidor 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, ya que puede efectuar cambios en el esquema de base de datos, pero mantener funcionalidad obsoleta por compatibilidad, especialmente con plugins o funciones que se puedan seguir usando.
Plugins como WP SuperCache, basado en WP Cache 2 de Gallir (en el antiguo blog de Gallir encontramos una descripción de cómo funciona y actúa WP-Cache 2), son imprescindibles para reducir los accesos de datos a mysql. Pero en algunos casos hemos encontrado problemas debido a malas actualizaciones de WordPress que se llevaban arrastrando varias versiones atrás.
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, en memoria a través de módulos memcached a nivel de servidor web, usando sistemas de proxy caché tipo Squid o infinidad de soluciones más. Personalmente creo que este tipo de cosas hay que hacerlas después de asegurarse que la parte de 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 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. Evidentemente tiene más sentido optar por soluciones basadas en memoria, como memcached, pero no disponemos de estas opciones en todos los entornos.
Hay otras situaciones en las que un sólo 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.
Nosotros en Blackslot empezamos por hacer un diagnóstico de la aplicación web, en el caso de basarse en wordpress limpiar el theme y el sitio web de funciones y plugins desactualizados, comprobar el buen estado de la base de datos para el CMS en cuestión, desarrollar plugins o themes que utilicen la última versión de la api y si fuese necesario buscar soluciones a nivel de sistema que mejoren el rendimiento de la aplicación.
Estas soluciones pueden ser desde realizar optimizaciones del servidor web y la base de datos, implantar soluciones de cache en memoria, opcode cache para php, distribuir el contenido estático del blog entre varios servidores o servicios de terceros (cloud o no, dependiendo de los requisitos del cliente) hasta soluciones más avanzadas para sitios web de gran cantidad de datos y tráfico.
No siempre una solución puede ser la cura a todas las enfermedades. Se suele escuchar por ejemplo que un tipo de motor de almacenamiento en mysql frente a otro, como el caso de 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 de menos rendimiento que algún otro tipo de servidor de base de datos, o frecuentemente que cachear en disco penalice mucho más que almacenar en la base de datos. No se pueden tratar todos los casos por igual en problemas de rendimiento web.
Por lo general hemos tenido alguna experiencia con clientes que teniendo un servidor dedicado saturado con prestaciones no precisamente moderadas, hemos podido migrarles a uno de nuestros servidores HyperV R2 con Linux ahorrándose, con sólo algunos cambios en su cms y últimas versiones en tecnologías de servidor, bastante dinero en hardware al mes.
