Tiempo de reflexión en pruebas de carga: cómo fijarlo

El tiempo de reflexión en pruebas de carga es la pausa que hace un usuario virtual entre dos acciones, y representa los segundos que una persona real pasa leyendo una página o rellenando un formulario. Decide cuánta presión ejerce cada usuario virtual: cuanto más larga es la pausa, menos peticiones por segundo envía el mismo número de usuarios. Mídelo con datos de usuarios reales, hazlo variar al azar alrededor de ese valor y escríbelo en el script con el comando de pausa de tu herramienta.

Es solo aritmética, sin ninguna prueba detrás: una petición por vuelta, una respuesta en 0,5 segundos, y el número de usuarios dividido entre (tiempo de respuesta + tiempo de reflexión).

¿Qué es el tiempo de reflexión en pruebas de carga?

El tiempo de reflexión es la espera deliberada que un script de prueba introduce entre los pasos de un recorrido de usuario. Reproduce la parte humana de una sesión: leer, comparar, escribir.

En el script de una tienda va entre «abrir la ficha del producto» y «añadir al carrito», fuera de cualquier petición. La guía de LoadFocus sobre los retardos en una prueba de carga lo separa del retardo de rampa, que añade usuarios poco a poco, y del retardo de arranque entre un usuario y el siguiente, y señala que muchas herramientas llaman «delay» a secas al retardo de rampa. Cuando una herramienta ofrezca un campo «delay», comprueba a cuál de los tres se refiere.

¿Por qué el tiempo de reflexión cambia la carga con el mismo número de usuarios?

Con un número fijo de usuarios virtuales, cada uno espera una respuesta, hace una pausa y solo entonces envía la siguiente petición. Su vuelta dura el tiempo de respuesta más el tiempo de reflexión, así que cada segundo de pausa añadido reduce las peticiones que cada usuario envía por segundo.

Cien usuarios sin pausa envían 200 peticiones por segundo con una respuesta de 0,5 segundos; con una pausa de 5 segundos envían unas 18, de modo que dos pruebas «con 100 usuarios» pueden ser muy distintas. La documentación de k6 describe el mismo efecto para su modelo cerrado: la siguiente iteración solo empieza cuando termina la anterior, así que las respuestas más lentas también bajan el ritmo (comprobado el 9 de octubre de 2026).

Recortar el tiempo de reflexión para sacar más carga de menos usuarios tiene un coste: veinte usuarios sin pausas pueden igualar el ritmo de peticiones de varios cientos que sí hacen pausas, y aun así mantienen abiertas muchas menos sesiones y conexiones que producción.

¿Qué diferencia hay entre tiempo de reflexión y pacing?

El tiempo de reflexión es una pausa después de un paso, así que una vuelta se alarga en cuanto las respuestas se vuelven lentas. El pacing fija el tiempo entre el inicio de una vuelta y el inicio de la siguiente, y acorta la espera cuando el trabajo ha tardado más.

Con un pacing de 30 segundos, un usuario empieza una vuelta cada 30 segundos tanto si sus peticiones tardaron 2 segundos como 20, lo que encaja con pruebas construidas a partir de volúmenes de negocio como «500 pedidos por hora». La documentación de constant_pacing en Locust detalla el caso límite: si la tarea dura más que el intervalo, la espera baja a cero (comprobado el 9 de octubre de 2026). Muchos scripts combinan ambos, con tiempo de reflexión entre pasos y pacing sobre la vuelta completa.

¿El tiempo de reflexión debe ser fijo o aleatorio?

Aleatorio, alrededor de una media que hayas medido. Una pausa fija mantiene al mismo paso a los usuarios que arrancaron juntos, que llegan a la misma página en el mismo momento, vuelta tras vuelta.

Esas oleadas sincronizadas pueden crear picos que producción nunca ve, y una pausa aleatoria reparte a los usuarios. Mantén la media donde la sitúan tus datos: una pausa uniforme entre 2 y 8 segundos da 5 de media, la misma carga media que una pausa fija de 5 segundos. La distribución uniforme es la opción sencilla por defecto; una normal (gaussiana) agrupa las pausas alrededor de un valor típico, y una exponencial da muchas esperas cortas y unas pocas largas.

¿Cómo eliges los valores del tiempo de reflexión?

Sácalos de lo que hacen los usuarios reales en cada paso, con tu analítica web, los logs de acceso o una herramienta de monitorización de usuarios reales (RUM). Usa un valor distinto por paso, porque leer una ficha de producto lleva más tiempo que pulsar un botón.

El tiempo en la página que da la analítica, o el intervalo entre peticiones consecutivas de una misma sesión en los logs de acceso, se acerca al tiempo de reflexión de ese paso. Toma la mediana como pausa media y la dispersión para fijar el rango aleatorio, y descarta los tiempos muertos, como una pestaña abierta durante la comida.

Una API a la que llaman otros programas no tiene a ningún humano en el bucle, así que modela directamente su ritmo de peticiones. Si no tienes datos, apunta en el plan de prueba los valores que supusiste para que una prueba posterior los sustituya; la guía paso a paso para hacer una prueba de carga muestra dónde encajan.

¿Cómo se añade tiempo de reflexión en k6, JMeter, Gatling, Locust y Artillery?

Cada herramienta tiene su propio comando de pausa, y la mayoría ofrece además pacing o un control de ritmo.

Los datos de la tabla de arriba y de las notas siguientes salen de la documentación de cada proyecto, comprobados el 9 de octubre de 2026; las cinco herramientas aparecen en nuestro repaso de herramientas de pruebas de carga open source.

k6. sleep(t) pausa al usuario virtual durante t segundos; la documentación construye pausas aleatorias con Math.random() o con randomIntBetween() de k6-utils:

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // de 2 a 8 segundos
  http.get("https://example.com/cart");
}

JMeter. Entre los timers, el Constant Timer toma un retardo en milisegundos, los Uniform y Gaussian Random Timers suman una parte aleatoria a un desfase fijo, y el Constant Throughput Timer varía sus pausas para mantener un objetivo de muestras por minuto. Un timer se ejecuta antes de cada sampler de su ámbito, así que un solo timer al nivel del Thread Group hace una pausa antes de cada petición.

Gatling. pause(2, 8) espera un tiempo aleatorio uniforme, y pace(30) dentro de un bucle lo ejecuta como mucho una vez cada 30 segundos. A nivel de simulación puedes pasar todas las pausas a una distribución normal o exponencial, o desactivarlas con disablePauses().

Locust. wait_time se aplica después de cada tarea, así que una tarea con dos peticiones bajo constant_throughput(2) envía cuatro peticiones por segundo y por usuario.

Artillery. Un paso think hace una pausa de un número de segundos, y un ajuste think.jitter en config.http.defaults añade variación aleatoria a cada paso think. Para ver dos de estas herramientas cara a cara, consulta k6 vs Artillery.

¿Importa el tiempo de reflexión en una prueba por tasa de llegada?

Menos, en lo que toca al ritmo de peticiones. Cuando la herramienta lanza nuevas iteraciones a un ritmo fijo, las pausas deciden cuánto tiempo se queda cada usuario y, por tanto, cuántos están activos a la vez.

Los ejecutores por tasa de llegada de k6 marcan el ritmo de las iteraciones con su tasa, y la documentación desaconseja un sleep al final de la iteración; las fases de carga de Artillery crean igualmente un número fijo de nuevos usuarios virtuales por segundo (ambos comprobados el 9 de octubre de 2026). El tiempo de reflexión entre pasos sigue dando forma a cada sesión.

¿Cómo fijan el tiempo de reflexión las herramientas de script de LoadFocus?

Lo escriben en el script de k6 o JMeter como valor inicial, para que lo ajustes después.

La importación desde cURL, HAR, Postman u OpenAPI convierte una petición capturada en un script de k6 que termina cada iteración con sleep(1); trata ese segundo como un valor provisional que debes sustituir por tus mediciones. El generador de pruebas con IA de LoadFocus tiene la instrucción de dar a cada paso un tiempo de reflexión, lo escribe como sleep() para k6 o como Constant Timer para JMeter, y avisa cuando un escenario de varios pasos no tiene ninguno.

FAQ

¿Se puede hacer una prueba de carga sin tiempo de reflexión? Sí, para encontrar el rendimiento máximo de un endpoint o para una prueba de estrés, siempre que presentes el resultado en peticiones por segundo. Dice poco sobre cuántos usuarios reales puede atender el sistema.

¿El tiempo de reflexión cuenta en el tiempo de respuesta? No en los tiempos de cada petición. En k6, http_req_duration cubre el envío, la espera y la recepción, mientras que iteration_duration cubre la vuelta completa (referencia de métricas, comprobado el 9 de octubre de 2026). Un Transaction Controller de JMeter deja los timers fuera de su tiempo, salvo que marques la opción que los incluye.

Lecturas relacionadas

• Modelo de carga abierto vs cerrado: cuál usar y cuándo
• Ley de Little en pruebas de carga: dimensionar y comprobar
• Cómo hacer una prueba de carga: guía paso a paso
• Teoría de colas: qué es y por qué se dispara la latencia

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.