En este articulo resalta:
El número de usuarios concurrentes no debe considerarse como entrada para el Load Testing , sino como el resultado de una serie de factores.Esto viene al caso de que comúnmente uno define los escenarios de Performance o de pruebas de Carga de la manera: “La aplicación debe soportar un máximo de 250 usuarios concurrentes” poniendo implícitamente la cantidad e usuarios concurrentes como parámetro de entrada para las pruebas.
Se puede observar como ese valor no puede ser entrada con un ejemplo (Similar al del articulo de Alberto):
Hay 3 usuarios distintos que no se conocen entre si (van a tener acciones diferentes y desincronizadas) y visitan la pagina de estado de cuenta de su banco 3 días consecutivos.
1º Día
El Usuario 1 inicia sesión a las 12:00; el Usuario 2 inicia sesión a las 12:01 y el Usuario 3 inicia sesión a las 12:02 y cada uno de sus escenarios consiste en Login-> Home Page-> Cuenta Pesos ->Cuenta Dolares. Cada uno de los usuarios se toma 10 segundos mirando cada pagina (Think Time) antes de pasar a la siguiente; Si el tiempo de respuesta de cada pagina es de5 segundos (tiempo que tarda en cargar) las sesiones de los 3 usuarios no se solaparan por lo que no habría usuarios concurrentes ya que el Usuario 1 va a recibir y ver cada una de las paginas antes de que el Usuario 2 inicie su sesión y el Usuario 2 va poder hacer lo mismo antes de que el Usuario 3 inicie su sesión.
2º Día
En el 2º día el tiempo de respuesta de cada pagina aumenta al doble (10 segundos) pero el tiempo que le toma a cada usuario leer la pagina sigue siendo de 10 segundos, por lo que cada sesión tendra un tiempo total de 80 segundos en lugar de los 60 segundos que antes tomaba. Este cambio en la velocidad de carga de pagina (Response Time) produce 2 usuarios concurrentes donde antes no los había, superponiendo las tareas del Usuario 1 con las del Usuario 2 y luego las del Usuario 2 con las del Usuario 3 como se ve en el gráfico.
3º Día
En el 3º día el tiempo de respuesta baja aun mas, llegando a 30 segundos el tiempo de respuesta de cada pagina, tardando 160 segundos cada sesión de usuario. Esto provoca que las sesiones del Usuario 1 y Usuario 2 se superpongan por 60 segundos generando 2 usuarios concurrentes, luego se genera 3 usuarios son currentes con la superposición de las sesiones del Usuario 1, Usuario 2 y Usuario 3 para luego quedar en 2 usuarios concurrentes.
Como se ve en los ejemplos el número de usuarios concurrentes no es una medida de la prueba de carga, ya que la carga fue idéntica en los 3 casos: tres usuarios, entrando al sistema en lapsos de un minuto, ven cuatro páginas cada uno con 10 segundos de Think Time por página.
En conclusión:
El número de usuarios concurrentes fue el resultado de la prueba de Carga: es una medida de la habilidad del sitio web para manejar una carga especifica. Un sitio web más lento da lugar a más usuarios concurrentes.Cuando se trata de medir la escalabilidad de un sitio Web, resulta que el número de usuarios concurrentes ni siquiera es útil como resultado de la prueba de carga.
Si el sitio Web es un poco lento, el número de usuarios concurrentes aumenta. Si es realmente lento, una gran cantidad de usuarios reales lo abandonan, lo que reduce el número de usuarios concurrentes. Pero, por otra parte, si un sitio Web es muy rápido las sesiones se completan más rápidamente, reduciendo también el número de usuarios concurrentes.
La conclusión es que los usuarios concurrentes es una medida peligrosamente engañosa, es un indicador que puede ser utilizada de muchas maneras pero es prácticamente garantizado que da resultados cuestionables.La pregunta inmediata es: ¿Qué medida debería usar en su lugar?
Para describir una entrada de carga, se puede utilizar la métrica inicio de sesiones de usuario por hora ya que es constante e independiente de la performance de la aplicación.
Fuente: http://josepablosarco.wordpress.com/2009/01/13/usuarios-concurrentes-concurrent-users/
No hay comentarios.:
Publicar un comentario