¿Cómo cálculo cuantos usuarios reales estoy simulando?
En primer lugar, vamos a calcular la carga real que se generaría.
Cálculo de la carga generada por un usuario real
Un usuario real, ejecutando una transacción determinada en el sistema, tardaría un tiempo determinado y generaría un numero de peticiones en los servidores
La carga generada por este usuario, a lo largo del tiempo, la podemos calcular como
siendo número_de_peticiones el de la transacción (3 en el gráfico) y número_de_ejecuciones las veces que ejecutamos la transacción con ese usuario (una única vez el gráfico). Si ejecutamos 2 veces la transacción, la carga generada será
La carga generada será, igual que anteriomente:
Mostrando entradas con la etiqueta optimización. Mostrar todas las entradas
Mostrando entradas con la etiqueta optimización. Mostrar todas las entradas
miércoles, 15 de abril de 2009
Relación entre Usuarios Virtuales y Usuarios Reales en pruebas de carga (II)
martes, 10 de marzo de 2009
Relación entre Usuarios Virtuales y Usuarios Reales en pruebas de carga (I)
Estas son unas de las grandes preguntas de las pruebas de carga (stress, rendimiento o como quieras denominarlas) ¿A cuantos usuarios reales representan los usuarios virtuales utilizados en la prueba? ¿Cuantos usuarios virtuales necesito para simular el numero de usuarios reales que habrá en el sistema? Aquí os dejo mi aproximación al problema, y mi solución (discutible, como todas) ¿Qué es un usuario virtual? Las herramientas de pruebas de carga simulan usuarios humanos o reales (UR) por “usuarios virtuales”(UV). Cada UV emula las acciones de usuarios reales ejecutando los mismos procesos de negocio. Por cada acción que realiza el UV, la herramienta envia las paquetes de datos al servidor o sistema de servidores, y espera la respuesta. Incrementando el número de usuarios virtuales, se incrementa la carga en el sistema. Mientras que una estación de trabajo únicamente puede ser utilizada simultáneamente por un usuario real, varios usuarios virtuales pueden ejecutarse concurrentemente en un único puesto. ¿Cuál es el objetivo de una prueba de carga?
La justificación que se presenta a continuación es una forma básica de estimar el número de usuarios virtuales por cada usuario real, que puede ser complementada con factores correctores que dependen del sistema bajo prueba, pero no modifican la esencia del planteamiento. En general, el coste de averiguar estos factores y su relación con el sistema no compensa los beneficios de su aplicación
Para justificar la fórmula utilizada en el cálculo del ratio entre usuarios reales (UR) y virtuales (UV), presentamos a continuación los conceptos y razonamientos utilizados:
¿Qué incluye una transacción contra el sistema?
Lanzar contra el sistema bajo prueba una carga similar a la esperada en
producción, para obtener los indicadores más significativos que nos permitan
evaluar el comportamiento de este respecto a la demanda realizada.
¿Cuál es la mejor forma de realizar la prueba de carga?
- Con usuarios reales.
- Un usuario Virtual por cada Usuario real, realizando la ejecución tal y como se grabó (es decir, con los “think time” que se grabaron). Si se tiene la posibilidad de utilizar tantos usuarios virtuales como reales se estiman en producción, esta es la forma recomendada.
¿Por qué utilizamos un número de Usuarios Virtuales inferior al de Reales?
- Coste de las herramientas: las licencias de las herramientas de pruebas de carga suelen estar asociadas al numero de usuarios virtuales concurrentes. A mayor número de UV concurrentes, mayor coste.
- Recursos necesarios para la ejecución: generalmente, cada usuario virtual es un hilo o proceso, al que se le asignan unos determinados recursos físicos (RAM, %CPU, etc). A mayor número de UV, más recursos son necesarios.
Leer más...
lunes, 29 de enero de 2007
Optimizando la realización de pruebas: uso de métricas
Durante el diseño y la ejecución de las pruebas debemos recoger diferentes métricas. La utilidad más habitual es informar al responsable del proyecto del estado del sistema bajo prueba: defectos encontrados, severidad de los mismos, etc.
Habitualmente también se recogen métricas para conocer el grado de cobertura que se ha conseguido con la ejecución de las pruebas: casos de prueba propuestos, ejecutados, fallidos, no ejecutados, bloqueados, etc.
Pero el responsable de pruebas debe prever también la recogida de información suficiente para hacer más efectivas las pruebas realizadas en cada iteración. "Hacer más efectiva" significa aquí detectar el mayor numero posible de errores, o errores más importantes.
Para esto, debemos pensar con antelación cual será nuestra estrategia de mejora de la efectividad, de cara a recoger la información necesaria. Algunas de las suposiciones que podemos seguir son:
Los errores tienden a "agruparse" (1):
En este caso, deberemos recoger información que nos permita trazar cada error detectado durante las pruebas con la zona en la que se ha producido. Una vez finalizado el ciclo de pruebas, podremos ver las zonas en las que debemos poner mayor atención en los siguientes ciclos de pruebas y en cuales podemos disminuir la intensidad o tomar medidas de mejora.
A la hora de determinar o analizar las zonas, podemos tener en cuenta los distintos factores que determinan el éxito o fracaso durante un proceso de test (2):
Referencias
Suscribirse a:
Entradas (Atom)
