Definición:
En el ámbito de las pruebas de rendimiento, se define el Think Time o Tiempo de espera como el intervalo de tiempo que simula los instantes en los cuales un usuario de la aplicación está ocupado en realizar tareas de manera local.
- Ejemplos:
- Un lector de un periódico on-line se encuentra leyendo una noticia.
- Gráficamente:
- El proceso de compra de un producto por parte de un usuario, desde el momento que solicita la compra hasta que esta se cumplimenta, podemos representarlo de la siguiente forma:
El tiempo total empleado en el proceso de compra se puede expresar como:
- T. Resp1 y T. Resp2 son los tiempos de respuesta obtenidos desde que el usuario realiza una petición hasta que obtiene la respuesta por parte de la aplicación.
- T. Cump. es el tiempo que el usuario tarda en cumplimentar los datos del formulario de compra. Desde el punto de vista del sistema bajo pruebas, la aplicación se encuentra a la espera de recibir una nueva petición y es por ello que se le denomina Tiempo de Espera.
El Tiempo de Espera dependerá de aspectos como:
- La operativa funcional: formularios con gran cantidad de datos, páginas con grandes cantidades de información, etc...
- La experiencia de los usuarios: usuarios expertos navegan más rápido que usuarios nobeles.
- El estrés de los usuarios.
El "problema" del Think Time:
El think time es un parámetro que podemos modificar en fase de ejecución de pruebas para:
- Conseguir mayores cargas cuando tenemos limitaciones en el número de licencias de usuarios virtuales. Es decir podemos aumentar la concurrencia operacional, manteniendo la concurrencia a nivel de aplicación:
- Ejemplo: 1.000 usuarios realizando, cada uno ellos, una petición cada 4 a., producen la misma carga que 500 usuarios realizando peticiones cada 2 a. Con un menor número de usuarios virtuales (VUsers) conseguiremos simular un mayor número de usuarios reales (RUsers)
- Sobrecargar el sistema simulando situaciones de estrés o picos de actividad. Por ejemplo la puesta a la venta de un producto estrella, una oferta limitada en el tiempo, etc, ....
En el caso más extremo, es posible llegar a prescindir del Think Time en las pruebas de rendimiento. También puede darse la situación de que la propia operativa de la aplicación implique que no sea aplicable un Think Time (por ejemplo, las pruebas de rendimiento unitarias de un servicio de negocio tipo web service, a menudo involucran scripts con una única petición). Cuando se prescinde del think time en nuestros parámetros de ejecución debemos tener en cuenta que:
- El consumo de recursos en los inyectores de carga es mucho mayor (principalmente de CPU), pudiendo llegar a convertirse en un cuello de botella y enmascar los resultados.
- Pueden existir elementos hardware o software cuyo funcionamiento depende directamente del número de conexiones reales establecidas con ellos.
- No se simula de manera realista cargas a nivel de concurrencia a nivel de aplicación.
¿Qué criterios sigues para tratar el think time en tus pruebas de prestaciones?. ¿Qué dudas plantea en los resultados?.... dejanos tu opinión para tratar de mejorar entre todos.
Es necesario su inclusión cuando se requiere realizar una operativa que se asemeje al mundo real, esto nos dará un valor mas real a nuestras pruebas. Como siempre excelente información la que se encuentra uno en este sitio.
ResponderEliminarEn cuanto a los criterios para tratar el think time, creo que lo mas sensato es hacer un muestreo estadistico entre los usuarios finales, e identificar cual es el tiempo promedio que se tarda cada perfil de usuario que opera el sistema, y en base a promedios, podemos configurar el think time agrupando tambien por niveles de usuarios de acuerdo a su experiencia en el sistema(puede ser usuarios avanzados, medianos, y principiantes)
ResponderEliminarMuchas gracias por tu contribución Carlos.
Eliminarla verdad es que el problema del Think Time se vuelve farragoso cuanto más se estudia:
1) Si descendemos el Think Time podemos simular una mayor concurrencia operacional, pero perdemos la visión de usuario.
2) Si intentamos simular los tiempos de los usuarios reales, es posible que nuestra licencia se quede corta para simular la concurrencia operacional.
Un saludo desde Julián Camarillo.
Un caso práctico, fue la grabación de un ciclo de trabajo de un Data Warehouse.
ResponderEliminarAl hacer una consulta, tardaba bastante en traer los resultados. El script que resultaba grabado eran múltiples sentencias
de cada vez que conectaba con el servidor para ver si se había traido la información.
Por ejemplo se grababan 37 sentencias iguales hasta que traía la información finalmente. En otra grabación podría ocurrir que en vez de
las 37 anteriores, se grabaran 29 sentencias dependiendo de lo que tardara el servidor.
Mientras intentaba traer la información, mostraba un mensaje, de:
"Su petición se está procesando. Espere un momento por favor."
Una manera de habilitar el script fue con un bucle, con la ejecución de la llamada, un tiempo de espera, de 5 segundos aproximadamente,
que se realizara hasta que desapareciera el mensaje de:
"Su petición se está procesando. Espere un momento por favor."
lo que significaba que ya se había traido la información.
Luego el think_time () fue una posible solución, para la ejecución de dicho script.
Saludos,
Muchas gracias por tu aportación.
ResponderEliminarLa solución que comentas es muy creativa y aporta un aspecto interesante y que no hemos tratado en la entrada: utilizar el think time como elemento para sincronizar las peticiones de un script y conseguir el correcto funcionamiento.
Hola, por aportar al debate, se puede enfocar de la siguiente manera
ResponderEliminarRespecto a las solicitudes asíncronas, habría que ver si es posible "encajarla" en el ciclo de prueba, de manera que se pueda seguir con la navegación o si es bloqueante para la misma.Por ejemplo una página que contenga un enlace a un vídeo que tarde en cargarse, pero que no impida realziar la navegación por el resto de marcos de la misma .
Para ello se puede realizar un enfoque dependiendo de las capacidades de la herramienta, como una subtransacción aparte, el lanzamiento de un script en un lenguaje multihebra...etc.
Por otro lado ,una validación de los tiempos de espera se podría hacer realizando la misma prueba ,con y sin los mismos y realizar una comparativa de los puntos de saturación ,consumo de recursos, concurrencia real...etc.
Espero que esto sirva para aclarar el asunto (o dar mi opinión al menos)
Saludos
En entornos tan complejos como lo es un datawarehouse, creo que lo mas viable seria hacer pruebas divididas por cada capa de la arquitectura de este, sobre todo por que no se tiene el control y no se sabe con certeza cuanto va a tardar en procesar la informacion en cada capa pero claro, esto dependiendo si se quiere o no un flujo end to end.
ResponderEliminarComo siempre es un privilegio comentar temas con gente experta como ustedes. Un saludo a todos desde Mexico.