Mostrando entradas con la etiqueta resultados. Mostrar todas las entradas
Mostrando entradas con la etiqueta resultados. Mostrar todas las entradas

miércoles, 15 de abril de 2009

Relación entre Usuarios Virtuales y Usuarios Reales en pruebas de carga (II)

¿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:


Leer más...

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)

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?
  • Lo denominado como thinking time o tiempo del usuario
    • Tiempo que el usuario tarda en leer, reaccionar y escribir en la pantalla (factor humano)
    • Tiempo de procesamiento de la capa cliente (navegador) de la aplicación
  • El resto, tiempo asociado al sistema servidor
    • Tiempo empleado en las comunicaciones cliente-servidor
    • Tiempo empleado en el procesamiento en servidor

¿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?
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...

miércoles, 10 de enero de 2007

Oráculos

Para tener una prueba bien diseñada es necesario conocer de antemano el resultado de su ejecución. Un oráculo es un elemento o artefacto que nos permite conocer el resultado esperado de la ejecución de una prueba. Por ejemplo:

- Otra aplicación o sistema.
- Un resultado calculado por un método manual
- Datos históricos cuya validez ya ha sido comprobada en la realidad

La utilización o no de determinados oráculos en nuestras pruebas es una decisión que debe plantearse, y resolverse en la medida de lo posible, en la fase de Estrategia, ya que pueden conllevar actividades de preparación que es necesario acometer antes del diseño y/o la ejecución de las pruebas.

En este sentido es necesario evaluar siempre el coste/beneficio de su utilización, la fiabilidad del oráculo y sus necesidades de mantenimiento.

Por ejemplo, es muy común que a la hora de verificar un sistema en el que está implicado un cálculo complejo, el equipo de pruebas se prepare como oráculo una hoja de cálculo (excel o similaar) que lo refleja. Esto conlleva, entre otros, los siguientes inconvenientes:

  • Quien prepara la hoja debe llegar a conocer con detalle toda la complejidad del cálculo. Si la información que llega a quien lo implementa en el sistema y a quien implementa el oráculo no es exactamente la misma y no se interpreta de la misma forma, los resultados de ambos pueden no ser coincidentes.
  • Pueden producirse errores al preparar la hoja de cálculo
  • Un error en las especificaciones del cálculo, producirá el mismo error en el oráculo, por lo que pasará inadvertido
  • El oráculo deberá tener al menos el mismo mantenimiento que el sistema.

Asi vemos que esta elección nos lleva a crear y mantener un oráculo de coste considerable en relación a la implementación en el sistema y cuya fiabilidad no es mucho mayor.

En estos casos, siempre que sea posible, es más aconsejable utilizar como oráculo elementos reales que se hayan procesado en el pasado utilizando ese mismo cálculo. Ya que generalmente un sistema se construirá para sustituir a un proceso manual o a otro sistema obsoleto, el propio cliente será capaz de proporcionar datos (entradas, salidas) validados en la realidad.

Leer más...