FASE 4: Creación de un modelo de comportamiento de usuarios
De las dos soluciones propuestas por el enunciado para llevar a cabo esta parte de la práctica, hemos escogido la que consiste en simular el comportamiento de los usuarios a partir de los datos recopilados de distintas fuentes.
La simulación del comportamiento de los usuarios se basa, como se ha dicho anteriormente, en imitar el comportamiento de los usuarios de otros sistemas similares al nuestro, y que ya han sido objeto de estudio. De esta manera, para nuestro sistema blogger Cuentameloami, clon de Ascodevida, podemos sacar distribuciones estadísticas reales de otros sistemas como las redes sociales, o incluso, de algunos estudios que se han hecho de Ascodevida, donde no aparece toda la información requerida, pero sí algunos datos interesantes.
En este apartado se hablará, entonces, de qué datos se necesitan sobre los usuarios para poder simular su comportamiento de la forma más realista posible, y de cómo se generan estos datos.
Número de usuarios y número de peticiones
Tanto el número de usuarios como el número de peticiones de Ascodevida es uno de los datos que aparecen en un análisis sobre el propio sistema a imitar. En este caso tenemos los valores exactos.
El número medio de usuarios de www.ascodevida.com es de 116692, y el número total de peticiones asciende a 583460 durante un dia. Para hacer el sistema un poco más realista, hemos separado un dia en dos franjas horarias. Durante el día (de 8h00 a 24h00) estimamos que se se conectan al sistema alrededor de 100000 usuarios, ya que los españoles son los que más consultan esta página web. El resto de usuarios (los 16692) los suponemos de países de la América Latina, y sus peticiones son durante la noche española.
Entonces, tiempo entre llegadas es fácil de conseguir: 100000 usuarios diurnos dividido entre las 16h del día (en segundos) es el número de clientes que entran por segundo a la web, y su inversa es el tiempo entre llegadas de usuarios. Según estos cálculos, durante el día entra un usuario cada 0.576 segundos.
Otro cálculo que sacamos de estos datos es que el número de peticiones que hace cada cliente es de 116692/583460 = 5.
Fuente: http://www.mustat.com/es/ascodevida.com
Peticiones de lectura/escritura
Según el artículo Traffic Characteristics and Communication Patterns in Blogosphere, sobre el total de peticiones que realiza un usuario en una página del tipo blogger, el 99.15% son de lectura y sólamente el 0.85% del total son de escritura. En nuestro caso, una petición de lectura puede ser sobre la página principal y sus páginas de continuación (que son las que muestran las historietas de 10 en 10); y una petición de escritura puede ser para escribir un post o bien para escribir un comentario en un post.
En la simulación que hemos llevado a cabo lo hemos implementado de la siguiente manera: Cada usuario va a generar 5 peticiones. La primera siempre será a la página de inicio. A partir de ahí, puede que lea (99.15%) o puede que escriba (0.85%). Si decide leer, puede que lea cualquiera de los posts de la página en la que está, o puede que avance a la siguiente página principal, todo de manera equiprobable. En caso de escribir, si está en una página principal, se realizará una petición de escritura de post, y en cambio, si está en una página de un post, va a escribir un comentario.
Fuente: http://open.bu.edu/xmlui/bitstream/handle/2144/1893/2006-033-blog-characterization.pdf?sequence=1
Tiempo entre peticiones
El tiempo entre las peticiones de cada usuario viene bien definido por esta distribución:
Distribución Lognormal, con parámetros = 1.789 i = 2.366
Figura 1
Fuente: http://dl.acm.org/citation.cfm?id=1644900
Alternativas
Apache JMeter
Es una aplicación opensource que se utiliza para lanzar peticiones de usuarios a un servidor. Originalmente fue creado para testear páginas web, pero después amplió su radio de funcionalidades.
Faban
Se utiliza, entre otras cosas, para testear servidores web, medir la escalabilidad, etc.
Al final hemos decidido crear nosotros mismos un programa hecho en Java que simula el comportamiento de los usuarios en nuestro sistema. El motivo de esta elección es que teníamos claro lo que tenía que hacer el simulador y nos resultó más sencillo programarlo que documentarnos para utilizar alguna de las herramientas antes descritas.
Simulación
A continuación explicaremos cómo se ha desarrollado la aplicación para simular el comportamiento de usuarios en la web.
Cada simulación es diferente debido al grado de aleatoriedad en el que se obtienen los datos, como el tiempo entre llegadas, nº de peticiones por cliente, etc. Es posible que se quiera repetir alguna de las simulaciones realizadas, así que hemos optado por la creación de un log para la posterior ejecucción del mismo. De esta manera podremos repetir de manera exacta la misma carga en el servidor.
La aplicación se divide en dos partes (como se puede observar en la siguiente imagen). En la parte superior es en la que se puede crear el log, indicando el tiempo de simulación y el tiempo entre llegadas de los clientes. Opcionalmente se puede añadir un nombre específico al log o sino la aplicación le pondrá uno por defecto.
Una vez elegidos los parámetros de la creación del log se pulsa “Crear log“. Cuando ha acabado la creación del log, automáticamente se seleccionará para la ejecucción. Con el botón “Seleccionar otro” se puede elegir un log que se haya creado previamente.
Detalles de implementación
Para desarrollar la aplicación hemos hecho uso de 5 clases y una serie de paquetes.
Clases :
- Simulador
- Clase principal que se encarga de crear y procesar el log.
- Cliente
- Simula el comportamiento de un cliente en la web, creando post y comentarios así como consultando las páginas.
- Peticion
- Se encarga de las conexiones con la base de datos y realiza las peticiones que el cliente demande.
- Escritor
- Escribe en el log las peticiones hechas por los clientes.
- Ventana
- Interfaz gráfica.
Paquetes / jars adicionales :
- MySQL Connector/JDBC
- Permite la conexión de java con la base de datos de MySQL
- commons-dbcp
- Implementación de un pool de conexiones.
- commons-pool
- Librería dependiente de commons-dbcp.
El funcionamiento del programa consiste en que el simulador crea clientes cada X tiempo y estos escriben en el log las acciones que van a realizar y el tiempo en el que las harán. Las acciones pueden ser tanto una consulta de una página o un post, escribir un comentario en un post o escribir un post.
Una vez acabado el tiempo de simulación los clientes se acaban y el se finaliza el log. Posteriormente cuando se procesa el log se recorren todas las entradas y se crea un hilo por cada una en el tiempo indicado.
A la hora de acceder concurrentemente a la base de datos, hay un problema. Varios hilos no pueden usar una misma conexión física con la base de datos simultáneamente, ya que la información enviada o recibida por cada uno de los hilos se entremezcla con la de los otros, haciendo imposible una escritura o lectura coherente en dicha conexión.
Hay varias soluciones para este problema:
- Abrir y cerrar una conexión cada vez que la necesitemos. De esta forma, cada hilo tendrá la suya propia. Esta solución en principio no es eficiente, puesto que establecer una conexión real con la base de datos es un proceso costoso. Abrir y cerrar conexiones con frecuencia puede hacer que el programa se ralentice.
- Usar una única conexión y sincronizar el acceso a ella desde los distintos hilos. Esta solución es mejor, pero requiere cierta disciplina al codificar, ya que hay que acordarse de poner siempre los synchronized (concurrencia en java) antes de hacer cualquier transacción con la base de datos. También tiene la pega de que los hilos deben esperar unos por otros.
- Finalmente, podemos tener varias conexiones abiertas, de forma que cuando un hilo necesite una, la "reserve" para su uso y cuando termine, la "libere" para que pueda ser usada por los demás hilos, todo ello sin abrir y cerrar la conexión cada vez. De esta forma, si hay conexiones disponibles, un hilo no tiene que esperar a que otro acabe. Esta solución es en principo la ideal y es lo que se conoce como un pool de conexiones.
Nos hemos decantado por utilizar la última forma. Hemos creado un pool de conexiones utilizando el paquete commons-dbcp. Cada petición obtiene una conexión del pool, y cuando ha acabado la transacción con la base de datos libera la conexión para que la pueda usar otro hilo.
El código del simulador se puede bajar de aquí : https://github.com/javi-cortes/msd