Posibles soluciones para esto hay varias:

• Estatificar el contenido: Pongamos por caso una aplicación típica cuyo contenido es dinámico: Fotolog, LiveJournal, etc. Este tipo de sitios Web podrían aumentar el hitrate notablemente estatificando el contenido de sus páginas. Si lo pensamos, realmente estas páginas solo se modifican en el momento en el que se añaden comentarios, fotos o similar, no sería excesivamente difícil estatificar todo el contenido y regenerarlo cuando haya modificaciones. Las ventajas son muchas. Aumentamos el hitrate de las maquinas ya que únicamente sirven contenido estático y disminuimos drásticamente los posibles fallos de seguridad que puedan surgir, al no haber aplicación, no hay fallo que buscar. En un post anterior ya comentamos posibles usos de proxy http para segregar contenido. Como en toda solución, tenía que tener algo negativo. Hay que modificar la aplicación para que genere contenido de naturaleza estática, esto normalmente a no ser que estemos desarrollando nosotros mismos la aplicación es realmente complicado ya que estatificar todo el contenido implicaría reescribir y convertir una aplicación que fue pensada como dinámica en un backend de generación de contenido estático.

• Cacheo dinámico de contenido: Esta es la solución de moda a día de hoy. Surgió como solución intermedia entre estatificar el contenido y sacarlo directamente de base de datos, la solución pasa por tener un numero de maquinas dedicadas que almacenan en RAM a modo de hash los resultados de las consultas a base de datos. Con esto conseguimos que, si esa consulta que íbamos a lanzar a la BD ha sido pedida recientemente, la recogemos directamente desde la memoria RAM del cache, y la devolvemos directamente. En caso de que no estuviera, la pedimos a la BD y la almacenamos en el cache, usando como “key” del hash la consulta a la base de datos serializada. De esta forma el rendimiento aumenta muchísimo al disminuir notablemente la interacción con la base de datos, con todo lo que eso implica (interfaz con la BD, consultas SQL, acceso a disco, recuperar la información, etc.). Como en toda solución, siempre hay aspectos a tener en cuenta, lo primero es la inversión en hardware, se necesitan maquinas con una CPU moderada pero con una cantidad de RAM muy elevada y además hay que hacer pequeños cambios en las aplicaciones que vayan a utilizar cacheo de contenido dinámico.

Si nos decidimos a implementar un cacheo de contenido dinámico, una de las principales aplicaciones en este mundo es memcached, esta aplicación fue desarrollada por Danga, que es la empresa creadora de LiveJournal. Desde su creación ha ido evolucionando y ganando adeptos hasta el punto en el que lo están utilizando sitios de tanta repercusión como: YouTube, LiveJournal, Slashdot, Wikipedia, SourceForge, WordPress.com, GameFAQs, Facebook, Digg, Twitter, Fotolog, BoardGameGeek, NYTimes.com, deviantART, Jamendo, Kayak, VxV y Netlog

Modificación de una aplicación para que funcione con memcached

Si finalmente nos decidimos a montar memcached como solución de cacheo dinámico, tenemos que afrontar el tema de las modificaciones a realizar en la aplicación. El aspecto positivo de todo esto es que si la aplicación que queremos montar bajo memcached es OpenSource hay muchas posibilidades de que alguien ya se haya ocupado de hacer las modificaciones, como es el caso de aplicaciones tan conocidas como WordPress,WikiMedia y phpBB. ¿Pero, y en el caso de que no sea una aplicación conocida, o incluso que estemos desarrollando nuestra propia aplicación? En este caso, la solución pasa por meter unas pocas llamadas en el flujo de la aplicación para que en vez de realizar la consulta directamente a la BD, primero consultemos al cache.

Un escenario típico podría ser el siguiente. Tenemos una función que realiza una consulta a la BD:

function get_foo (int userid) {
result = db_select("SELECT * FROM users WHERE userid = ?", userid);
return result;
}

Tras realizar las modificaciones, para que primero se consulte a memcached la función quedaría de la siguiente forma:
function get_foo (int userid) {
result = memcached_fetch("userrow:" + userid);
if (!result) {
result = db_select("SELECT * FROM users WHERE userid = ?", userid);
memcached_add("userrow:" + userid, result);
}
return result;
}
En este caso, primero consultamos al cache, si el cache tiene almacenada esa clave la devuelve directamente. En caso contrario, preguntamos a la base de datos y lo almacenamos en el cache para que las siguientes consultas sean desde RAM.

Así mismo, las actualizaciones en BD hay que modificarlas porque si no el cache empezaría a devolver información incorrecta, la forma más fácil de hacer esto es directamente desde la aplicación, en el momento en el que se produzca una actualización, directamente eliminamos esa “key” y la substituimos por la nueva de la siguiente forma:
function update_foo(int userid, string dbUpdateString) {
result = db_execute(dbUpdateString);
if (result) {
data = createUserDataFromDBString(dbUpdateString);
memcached_set("userrow:" + userid, data);
}
}

Con modificaciones similares las explicadas, y una buena configuración de la plataforma de cacheo, se consigue un hitrate de un 70%, esto quiere decir que un 70% de las peticiones le llegan directamente a memcached sin que llegue un solo byte a la BD.

En posteriores artículos haremos un ejemplo completo de cómo se monta un memcached con un par de ejemplillos de acceso y alguna estadística.