Вы находитесь на странице: 1из 8

Arquitectura Cache

Para entender a cabalidad este documento lea con atención el enunciado del problema ya
entregado con anterioridad.

La cache que se va a simular será una cache asociativa por conjuntos. El término asociativo se
refiere que todos los objetos están destinados a ser ubicados en una zona de la memoria cache y
nunca serán ubicados en ninguna otra. La zona donde se ubique el objeto dependerá del objeto
mismo. Si en un momento t(k) el objeto o_n será ubicado en la zona z_x entonces si en otro
instante de tiempo t(k+a), es decir más adelante, el mismo objeto o_n debe volver a la cache, se le
ubicara en la misma zona que en el momento previo t(k). Pero debido a que hay una gran
cantidad de objetos y la cache es de tamaño pequeño, una gran cantidad de objetos están
destinados a ocupar la misma zona o conjunto, por tanto la zona debe tener espacio para
acomodar a varios objetos. La cantidad de los objetos que ocupan un conjunto no debe ser
ilimitada ya que la cache no es un mapa, o una estructura tipo hash aunque su funcionamiento
pueda parecerse. Cuando el conjunto ya esté lleno, se debe aplicar una política de remplazo que
determine que objeto debe salir de la cache para dar lugar al nuevo. A continuación el siguiente
ejemplo:

Suponga la siguiente cache:

 Numero de conjuntos(N) N=2048


 Numero de espacios por conjunto(M), M=4
 Política de remplazo:LRU

Conjunto Elemento 0 Elemento 1 Elemento 2 Elemento 3


0
1
2
…..
2045
2046
2047

Una cache que puede almacenar 2048*4 objetos, es decir, 8192 o 8K objetos.

Para ubicar el conjunto donde pertenece el objeto se puede usar el hashcode del mismo, y para
ubicar el objeto dentro del conjunto se puede usar el equals de dicho objeto.

Por tanto los objetos cacheables deben sobre escribir la implementación de estos métodos.
De cada elemento se deberá conocer el tiempo sin haber sido referenciado, que es el número de
veces que se ha utilizado un elemento en el conjunto diferente a él. Del elemento también se
deberá conocer la frecuencia de uso, que es el número de veces que se ha requerido el objeto que
almacena el elemento.

Supóngase el conjunto 1650 de la cache anterior

Conjunto E0 E1 E2 E3
….
1650 Obj={pepe,ferrer,1234} Obj={claudia,fernandez,54234}
vida=4,frecuencia=3 vida=0,frecuencia=4
…..

Esta cache almacena objetos persona( los objetos de la cache no están limitados a ser de un solo
tipo como en una estructura de datos o collection).

El elemento 0 (E0) ha sido usado tres veces desde que está en la cache(frecuencia=3) el conjunto
ha sido accedido cuatro veces sin que sea él el necesitado (vida=4).

El elemento 1 (E1) ha sido usado tres veces desde que está en la cache(frecuencia=4) y la ultima
vez que se accedió al conjunto se accedió a él, ya que su vida es cero.

Supóngase que se agrega el siguiente objeto a la cache {juan, Ferrer,53435} y por su código hash
que es 4587445874 este queda en el conjunto 1650, ya que los elemento 2 y 3 estan vacios el
deberá quedar en uno de ellos, la cache quedaría asi entonces:

Hashcode=4587445874, entoces, numconjunto=4587445874 mod 2048=1650, se usa la operación


de modulo para garantizar que cualquier hashcode tiene su correspondiente conjunto. 2048 es el
número de conjuntos.

Conjunto E0 E1 E2 E3
….
1650 Obj={pepe,ferrer,1234} Obj={claudia,fernandez,54234} Obj={juan,
vida=5,frecuencia=3 vida=1,frecuencia=4 Ferrer,53435}
Frecuencia=0,
vida=0
…..
Y luego se agrega otro objeto {gladys, bustos,903845034}
Conjunto E0 E1 E2 E3
….
1650 Obj={pepe,ferrer,1234} Obj={claudia,fernandez,54234} Obj={juan, Obj={gladys,
vida=6,frecuencia=0 vida=2,frecuencia=4 Ferrer,53435} bustos,903845034}
Frecuencia=0, Frecuencia=0,
vida=1 vida=0
…..

Como se observa en rojo, cada vez que se usa el conjunto, la vida de sus elementos aumenta. En
este momento el objeto más viejo es el ubicado en E1.

Supóngase que se desea el objeto {juan, Ferrer,53435} por su hashcode la cache lo ubica en el
conjunto 1650 y el conjunto usando el equals lo ubica en el elemento 2. La frecuencia de uso de
este objeto aumenta y su vida a cero, ya que acabo de ser referenciado. La vida de los otros
aumenta ya que en este acceso no se les uso.

Conjunto E0 E1 E2 E3
….
1650 Obj={pepe,ferrer,1234} Obj={claudia,fernandez,54234} Obj={juan, Obj={gladys,
vida=7,frecuencia=0 vida=3,frecuencia=4 Ferrer,53435} bustos,903845034}
Frecuencia=1, Frecuencia=0,
vida=0 vida=1
…..

Se puede notar que al objeto que usaron, su vida pasa a ser cero y la de los demás a aumentar y su
frecuencia tambien aumenta.

Después de varios accesos el conjunto quedo asi:


Conjunto E0 E1 E2 E3
….
1650 Obj={pepe,ferrer,1234} Obj={claudia,fernandez,54234} Obj={juan, Obj={gladys,
vida=3,frecuencia=2 vida=7,frecuencia=4 Ferrer,53435} bustos,903845034}
Frecuencia=3, Frecuencia=1,
vida=1 vida=0
…..
En este momento, para este conjunto, el objeto más usado es el ubicado en el elemento 2 y el
más viejo, el que ha estado más tiempo sin usar en el conjunto es el objeto ubicado en el
elemento 1.

Ahora supóngase que un objeto cuyo hashcode lo ubico en el conjunto 1650 debe ingresar a la
cache, surge la pregunta: donde ubicarlo si el conjunto ya está lleno?

Ahí es donde interviene la política de remplazo. si se usa LRU (usado menos recientemente) se
deberá remplazar el elemento 1, el cual no ha sido usado hace 7 accesos o si se usa la política
LFU(usado menos frecuentemente) se deberá eliminar el elemento 3, que ha sido usado una vez
no más. Si se usa una política aleatoria, se podrá remplazar cualquiera.

La cache globalmente también debe poseer dos estadísticas importantes que es el número de
fallos que son las veces que se ha buscado un objeto en la cache y este no ha estado y el número
de éxitos, que son el número de veces que se ha buscado un objeto en la cache y este ha estado
allí. Una cache bien configurada minimiza los fallos maximizando los éxitos.

Se adjunta proyecto eclipse con lo explicado a continuación.


Diagrama de Clases
Arquitectura.

la cache debe ser independiente de la política y el lugar de donde provienen los datos.
Explicación Clases:
interface que define los métodos enviar
cuando se escriba un dato en la cache sea
creando o editando, se debe enviar al lugar
de destino del mismo ademas de quedar en
la cache. El método recibir es aquel que usa
la cache cuando un dato que se busca no
esta en ella, la cache debe pedirlo al origen
de datos ya almacenarlo en ella además de
entregarlo a quien lo pidió. El origen de
datos puede ser una base de datos o el
servidor. En estos métodos se implementa la
conexión a dicho origen.

Interface que implementa el método


“obtenerPosicionRemplazo” que recibe
como parámetro el arreglo de elementos del
conjunto para mirar cual es el más apto para
dejar la cache. Cualquier política (LRU,LFU o
Random) deberán implementar esta
interface.

Posee:
La frecuencia de uso
Valor que almacena
Vida, o numero de accesos al conjunto
donde no se ha usado este elemento.

Posee:
elementos o arreglo de objetos que
almacena el conjunto.
Una instancia de IPoliticaRemplazo que
determine el elemento que debe dejar la
cache cuando este conjunto ya está lleno.
Y size es el tamaño del conjunto.
Por constructor recibe la política y el tamaño
y posee los métodos get, para buscar un
objeto y put para guardar uno nuevo. Este es
el que utiliza la política de remplazo.
Conjuntos es el arreglo de conjuntos de la
cache. dataAccesor es una instancia de
IAccesoDatos que implementa la conexión
con el origen de datos, ya sea la base de
datos o el servidor. numeroConjuntos es el
numero de conjuntos de la cache y
sizeConjunto es el numero de elementos de
un conjunto. politica debe ser una instancia
de IPoliticaRemplazo que implemente la
lógica de remplazo en los conjutnos.
Los métodos get, para buscar un objeto y
put para guardar uno nuevo. Este es el que
utiliza la política de remplazo. cuando se
busca un objeto en la cache con get y este
no esta, el método usa dataAccesor para
obtenerlo del origen de datos, darlo a quien
lo pidió y guardarlo en la cacche. Put usa el
dataaccesor para enviar el dato que se
guarda en cache al origen de datos. Put
también guarda el dato en cache.

Cache al lado del servidor.

Cache L1

AccesoBD BD

Cache al lado del cliente.

Cache L1

RED(al
servidor)
AccesoBD
En este ejercicio, habrán objetos personas, 50000 en total en una base de datos de mysql que se
debe llamar “cache”. La generación de esas 50000 personas tarda alrededor de 2 minutos por
tanto la primera vez que se creen la aplicación se demorar en arrancar.

 Para el análisis de la cache del lado del servidor, variar el tamaño de la misma de un 10% a
un 50% del número de registros de la BD con pasos de 5%. La cache del cliente deberá de
ser un 20% dde la memoria del servidor en todos los casos. Esto para el punto 3a-i y 3a-ii
 Con una cache de servidor a un 10% del número de registros de la bd, variar el tamaño de
la cache del cliente de un 10 a un 100% del tamaño de la cache del servidor. Esto para el
punto 3a-i y 3a-iii.
 Para el punto b variar la cache de un 10% a un 50% del número de registros de la bd.
 Para el punto c variar la cache de un 1% a un 10% del número de registros de la cache.
 Con un numero de conjuntos en la cache de servidor de un 5% del número de registros de
la base de datos, mostrar el comportamiento de la cache con un tamaño de conjunto de
1,2, 4, y 8 elementos.
 Todos estos análisis son análisis en el tiempo, es decir, mostraran el número de fallos,
aciertos, tiempo de respuesta y uso de memoria en función del tiempo. Con una duración
de la prueba de 5 minutos.
 Para el punto a, donde las dos caches están en funcionamiento, monitorear el
comportamiento de la cache del servidor con hasta 10 clientes haciendo peticiones al
tiempo.
 Mostrar las graficas en función del número de clientes conectados.
 Uds deben hacer los métodos de la cache, (conjunto y cache), el accesor al servidor
AccesoNet, la aplicación cliente y servidor e implementar cada una de las políticas de
acceso.

Вам также может понравиться