Modelo de carga abierto vs cerrado: cuál usar y cuándo

Elegir un modelo de carga abierto vs cerrado depende sobre todo de cómo llegan los usuarios a tu sistema. Usa un modelo abierto, que inicia nuevas iteraciones a una tasa de llegada fija, para sitios web y API públicos donde los usuarios siguen llegando por lento que respondas, y un modelo cerrado, un número fijo de usuarios virtuales que esperan a que termine su iteración anterior, solo donde el propio sistema limita la concurrencia. La elección pesa sobre todo en saturación, cuando una prueba cerrada frena su propia carga y hace que el sistema parezca más sano de lo que está.

Los datos sobre las herramientas salen de la documentación de cada proyecto, comprobada el 9 de octubre de 2026.

¿Cuál es la diferencia entre un modelo de carga abierto y uno cerrado?

En un modelo abierto, el generador de carga decide cuándo llega el trabajo, y en uno cerrado lo decide el tiempo de respuesta del sistema.

La documentación de k6 lo explica sin rodeos: en el modelo cerrado, la siguiente iteración de un usuario virtual solo empieza cuando termina la anterior, mientras que en el modelo abierto las nuevas iteraciones llegan sin depender de que terminen las anteriores (comprobado el 9 de octubre de 2026). Una prueba cerrada con 50 usuarios virtuales nunca tiene más de 50 iteraciones en curso. Una prueba abierta a 50 iteraciones por segundo lanza 50 más cada segundo, y si cada una tarda más, se solapan más.

¿Por qué un modelo cerrado oculta la latencia cuando el sistema se satura?

Porque la prueba se ralentiza junto con el sistema. Cuando las respuestas tardan más, cada usuario de un modelo cerrado envía menos peticiones, y la carga baja justo cuando querías verla subir.

La documentación de k6 describe el efecto: respuestas más lentas significan iteraciones más largas y una tasa de llegada menor de iteraciones nuevas. La página de Gatling sobre modelos de carga va más allá y dice que usar un modelo cerrado contra un sistema que en realidad es abierto es una prueba rota que mide un comportamiento imaginario (comprobado el 9 de octubre de 2026).

Por eso una prueba cerrada muestra tiempos de respuesta que se estabilizan, ya que nunca puede haber más peticiones en curso que usuarios. Una prueba abierta muestra la cola creciendo, con tiempos de respuesta que suben mientras las llegadas superen lo que el sistema procesa. Esa segunda imagen es la que verían tus usuarios, y los tiempos de respuesta p95 y p99 que lees al final solo son tan fiables como el modelo de carga que los produjo.

La documentación de k6 señala que parte de la literatura sobre pruebas llama a este problema coordinated omission. Un artículo de USENIX de 2006 que cita la documentación de Gatling, Open Versus Closed: A Cautionary Tale, concluyó que los dos modelos dan resultados muy distintos incluso con la misma carga y las mismas demandas de servicio.

¿Qué modelo encaja con tu tráfico real?

Elige un modelo abierto para todo lo que el público puede alcanzar, y uno cerrado solo donde el propio sistema limita cuántos usuarios están activos a la vez.

La documentación de Gatling pone como ejemplos de sistemas cerrados los centros de llamadas con todos los operadores ocupados y los sitios de venta de entradas que ponen a los usuarios en cola cuando están al máximo, y dice que la mayoría de los sitios web se comportan como abiertos. Un proceso por lotes con un número fijo de workers, o un consumidor de colas con una concurrencia fija, también es cerrado. Las API públicas, las páginas web y los webhooks son abiertos: nada frena la siguiente petición porque la anterior haya ido lenta.

Muchos sistemas quedan en medio: una compradora llega a su propio ritmo y luego espera cada página dentro de la visita. El artículo citado lo llama modelo parcialmente abierto. En k6 o Gatling, fija la tasa de llegada de las sesiones y haz que cada iteración sea un recorrido de usuario completo, con sus propias pausas.

¿Cómo se configura cada modelo en k6?

Con el executor. constant-vus y ramping-vus dan un modelo cerrado, y constant-arrival-rate y ramping-arrival-rate, uno abierto.

Un escenario cerrado define executor: "constant-vus" con un número de vus y una duration. Un escenario abierto fija una tasa, y reservas por adelantado suficientes usuarios virtuales para mantenerla:

export const options = {
  scenarios: {
    open_model: {
      executor: "constant-arrival-rate",
      rate: 50,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 100,
    },
  },
  thresholds: {
    dropped_iterations: ["count<10"],
  },
};

k6 solo inicia una iteración si tiene un usuario virtual libre, y su documentación desaconseja apoyarse en maxVUs, porque añadir usuarios a mitad de la prueba puede sobrecargar el generador de carga. Cuando no hay ningún usuario libre, k6 registra una iteración descartada, lo que, avanzada la prueba, suele indicar que el sistema se está ralentizando. El umbral de arriba hace fallar la ejecución al llegar a diez. No pongas sleep() al final de una iteración con tasa de llegada, porque el executor ya marca el ritmo de los inicios (comprobado el 9 de octubre de 2026).

Si ejecutas scripts de k6 en LoadFocus, su ejecución de k6 en la nube toma la carga de la configuración de la prueba, y su validador de scripts avisa de que los escenarios con tasa de llegada se ejecutan allí con un número fijo de usuarios, así que la tasa de peticiones no se mantiene. Para una prueba de verdad con modelo abierto, ejecuta los executors de tasa de llegada con el propio k6, o en un servicio que los ejecute tal como están escritos.

¿Cómo expresan cada modelo Gatling, Locust y JMeter?

Gatling separa los dos modelos en su API, JMeter ofrece ambos mediante thread groups distintos y Locust está construido en torno a un número fijo de usuarios.

Gatling. Un escenario usa injectOpen o injectClosed. Los pasos abiertos como constantUsersPerSec y rampUsersPerSec fijan tasas de llegada, y los cerrados como constantConcurrentUsers y rampConcurrentUsers fijan la concurrencia. Un mismo perfil de inyección no puede mezclar los dos (comprobado el 9 de octubre de 2026).

Locust. Fijas un número de usuarios, y el wait_time de cada usuario controla la pausa entre tareas. constant_throughput y constant_pacing ajustan esa pausa para que cada usuario ejecute como mucho un número dado de tareas por segundo, pero la documentación dice que el tiempo de espera solo puede limitar el rendimiento y no lanza usuarios nuevos para alcanzar un objetivo. poisson() elige pausas aleatorias, que la documentación considera más cercanas a las llegadas reales. El ejemplo de la documentación para 500 iteraciones de tareas por segundo es constant_throughput(0.1) con 5.000 usuarios, un pool cerrado con mucho margen (comprobado el 9 de octubre de 2026).

JMeter. El Thread Group clásico es un pool cerrado de hilos. Los timers Constant Throughput y Precise Throughput acompasan ese pool hacia una tasa objetivo, y la referencia advierte de que el rendimiento baja si el servidor no da abasto o no hay suficientes hilos. Para las llegadas, JMeter 5.5 añadió el Open Model Thread Group, todavía marcado como experimental, con programaciones como rate(10/sec) random_arrivals(1 min). El plugin de la comunidad Arrivals Thread Group arranca hilos nuevos cuando todos los existentes están ocupados, con un límite de concurrencia como válvula de seguridad (comprobado el 9 de octubre de 2026).

¿Qué vigilar en una prueba con modelo abierto?

Vigila el generador de carga tan de cerca como el sistema bajo prueba. En un modelo abierto, un sistema lento significa más usuarios concurrentes de tu lado, y eso cuesta memoria y CPU.

Fija un techo, como maxVUs en k6 o el límite de concurrencia del plugin de JMeter, y trata alcanzarlo como un resultado: el sistema no pudo absorber la tasa que pediste.

FAQ

¿Un modelo de carga cerrado es alguna vez la opción correcta? Sí. Úsalo cuando el sistema real limite la concurrencia, como un pool fijo de workers, un consumidor de colas o un centro de llamadas, o cuando quieras saber cuántas sesiones simultáneas aguanta un componente. Para el tráfico web público encaja mejor un modelo abierto.

¿Añadir tiempo de reflexión convierte un modelo cerrado en uno abierto? No. El tiempo de reflexión reduce la frecuencia con la que cada usuario envía peticiones, pero cada usuario sigue esperando la respuesta anterior, así que un sistema lento sigue frenando la prueba. Solo una tasa de llegada fijada con independencia de los tiempos de respuesta da un modelo abierto.

¿Cuántos usuarios virtuales necesita una prueba con tasa de llegada? Los suficientes para cubrir todas las iteraciones en curso a la vez. La documentación de k6 sugiere la mediana de la duración de una iteración multiplicada por la tasa objetivo, más un margen para la variabilidad, ajustada con pruebas cortas antes de la prueba completa.

Lecturas relacionadas

• Coordinated omission: qué es y cómo evitarla
• Ley de Little en pruebas de carga: dimensionar y comprobar
• Tiempo de reflexión en pruebas de carga: cómo fijarlo
• Rendimiento vs latencia: cómo se relacionan bajo carga
• Ley de Amdahl: fórmula, ejemplos y límites
• 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.