Memoria caché. ¿Cuándo nos juega a favor y cuándo en contra?

En este tip mostraré dos ejemplos en los que en uno nos interesa el uso de la memoria en caché y otro en el que nos interesa tenerla deshabilitada.

Caso 1: a favor

Se trata del catálogo un sitio de música, que contiene varios reproductores (prelisteners) hechos en flash. A cada reproductor se le pasa un parámetro con el id del tema a reproducir.

Código :

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
   codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"
   width="135" height="20">
   <param name="movie" value="http://www.dostonos.com/player.swf?id=748f6a6d704de6ab82916c3dba0548b9">
   <param name="quality" value="high">
   <param name="bgcolor" value="#FFFFFF">
</object>

En la línea del param name="movie" se observa que el ID se le pasa al reproductor por URL (metodo GET). Funciona correctamente pero cada reproductor, al ser distinta la URL se baja del servidor nuevamente no aprovechándose el caché.
De este modo si ponía por ejemplo 30 reproductores, el peso de la página era enorme, porque se bajaban 30 copias del flash.
La solución fué no pasar el parámetro por URL sino por Flasvars, como se vé en la captura de abajo.

Código :

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
   codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"
   width="135" height="20">
   <param name="movie" value="http://www.dostonos.com/player.swf"> 
   <param name="quality" value="high">
   <param name="bgcolor" value="#FFFFFF">
   <param name="FlashVars" value="id=748f6a6d704de6ab82916c3dba0548b9" /> 
</object>

De esta manera, cada llamada al flash que está en el servidor es idéntica. Por lo tanto el primer reproductor lo baja del servidor, y los siguientes son instancias del mismo. Siguiendo el ejemplo, a un catálogo con 30 reproductores, solo tendremos que sumarle el peso de 1, aumentando notablemente la performance.

Nota: Para observar la diferencia, además de notarse en la velocidad de carga y reproducción de la página y los objetos Flash, se puede observar la carpeta de archivos temporales de Internet.
Si pasamos el ID por URL encontraríamos 30 copias del reproductor:

• player.swf
  
• player.swf(1)
  
• ....
  
• player.swf(29)

Si lo pasamos con Loadvars, en la misma carpeta solo habría 1:
player.swf

En este caso claramente el caché nos favoreció.
Por si a alguien le interesa ver el ejemplo "en vivo", les paso la url: dostonos.com

Caso 2: en contra

En este caso se trata de una aplicación hecha en Adbe Flex, con acceso a datos que leemos mediante un XML. Como estos datos varían, no tomamos directamente el .XML; lo generamos con un .php que lee la BD (podría haber sido un .asp o cualquier server-side) de la siguiente manera:

Código :

<mx:HTTPService id="phpService" url="http://www.misitio.com/recibeDatos.php" method="GET" ></mx:HTTPService>

En este caso la memoria caché nos juega en contra. Como la llamada al .php es siempre igual, la primera vez la toma del servidor pero las subsiguientes las toma del caché, haciendo que por más que los datos en nuestra BD hayan cambiado, el .XML resultante sea siempre igual.
La solución es cambiar la URL cada vez para obligar al navegador a consultar nuevamente la página del servidor. Para hacerlo agregamos a la URL un parámetro cualquiera que no se usará en el .php, su único objetivo es hacer que la URL sea siempre distinta.

Código :

</mx:Script>
   private function traerDatos():void{
      var randomNumber:Number=Math.random();   // generamos un numero aleatorio
      var oParam:Object = new Object();   // creamos un objeto para pasar al webservice
      oParam.id = randomNumber      // dentro del objeto creamos el id, que es lo que se pasará como parámetro
      this.phpService.send(oParam);       // llamamos al webservice
   }
</mx:Script>

Tomando este recaudo, cada llamada al .php será distinta por lo que no utilizará el caché. El resultado esperado es que si los datos en el servidor cambiaron, nuestro .XML cambiará y veremos reflejados esos cambios en la aplicación.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.