loadtest.app

Ley de Amdahl: fórmula, ejemplos y límites

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

La ley de Amdahl (Amdahl's law) dice que la aceleración que se obtiene al ejecutar un trabajo en paralelo está limitada por la parte que no puede ejecutarse en paralelo. Si una fracción p del trabajo se reparte entre n procesadores, servidores o hilos, la aceleración es S = 1 / ((1 − p) + p/n), y por mucho que crezca n nunca supera 1 / (1 − p). Con un 95 % de trabajo paralelo, el techo es de 20 veces, incluso con mil máquinas.

Las cifras de abajo son aritmética, sin ninguna prueba ejecutada detrás. Los artículos citados se comprobaron el 1 de noviembre de 2026.

Fracción paralela p	n = 2	n = 8	n = 64	n → ∞
0,50	1,33	1,78	1,97	2
0,90	1,82	4,71	8,77	10
0,95	1,90	5,93	15,42	20
0,99	1,98	7,48	39,26	100

¿Qué dice la ley en palabras sencillas?

Un trabajo no puede terminar más rápido que su parte secuencial, así que los workers adicionales solo acortan el resto. Cuando la parte paralela ya es pequeña frente a la secuencial, añadir workers apenas cambia el tiempo total.

Toma un trabajo de 10 segundos en el que 1 segundo es secuencial (un bloqueo, una escritura única) y 9 segundos se reparten por igual, es decir, p = 0,9. Ocho workers lo terminan en 1 + 9/8 = 2,125 segundos (4,71 veces más rápido); sesenta y cuatro necesitan unos 1,14 segundos. Nada lo baja de 1 segundo, así que 10 es el techo.

¿De dónde viene la ley?

Gene Amdahl presentó el argumento en 1967, en la AFIPS Spring Joint Computer Conference, en un artículo que defendía el enfoque de un solo procesador.

No hemos leído el texto completo de Validity of the single processor approach to achieving large scale computing capabilities. Mark Hill y Michael Marty lo resumen en Amdahl's Law in the Multicore Era (IEEE Computer, 2008): una fracción paralelizable sin límite y sin coste de planificación, el resto totalmente secuencial, y la aceleración descrita sin presentar ninguna ecuación («without presenting an equation»).

¿Qué significa para las pruebas de carga y de capacidad?

El rendimiento deja de crecer al ritmo de los servidores, hilos o pods en cuanto un componente compartido atiende una parte de cada petición de una en una. Una prueba de carga lo muestra como una curva de rendimiento que se aplana mientras sigues añadiendo capacidad.

El artículo de Neil Gunther de 2008, citado más abajo, escribe la misma ley como N / (1 + σ(N − 1)), con σ como fracción secuencial, y mide la escalabilidad como el rendimiento con N dividido entre el rendimiento con 1. En un sistema web, la parte secuencial es todo aquello por lo que cada petición tiene que pasar por turno: un bloqueo o una fila que actualiza cada petición, una única base de datos primaria que recibe todas las escrituras, un único consumidor de cola o una API de terceros con límite de peticiones.

¿Cómo encuentras la parte secuencial en una prueba de carga?

Ejecuta la misma prueba en varios niveles de carga y observa qué recurso se satura mientras el rendimiento se aplana. El componente que está en su límite cuando la capacidad extra deja de compensar es la parte secuencial, o la cola que tiene delante.

Señales típicas: el rendimiento se estanca aunque la capa de aplicación tiene CPU libre, las esperas crecen en un único punto compartido (bloqueos, conexiones a la base de datos, profundidad de la cola), y el tiempo de respuesta sube al mismo ritmo que los usuarios, que es la ley de Little ante un techo. Una ejecución con carga constante no puede mostrarlo, así que sube la carga por escalones. El ajuste Ramp Up Steps de LoadFocus añade usuarios virtuales en lotes iguales. El panel de capacidad de LoadFocus agrupa una ejecución terminada por usuarios virtuales activos y, en los planes de pago, muestra el p95, las peticiones por segundo y la tasa de error de cada escalón en las ejecuciones con un solo generador de carga. Solo indica un nivel de capacidad si la ejecución pasó por al menos tres escalones y el más alto fue al menos el doble del más bajo. No ajusta ningún modelo de escalabilidad, así que el ajuste de más abajo te toca a ti.

¿Qué es la ley de Gustafson?

Es el contrapunto: si el problema crece con la máquina, la parte secuencial sigue siendo pequeña y la aceleración crece casi de forma lineal. Amdahl fija el trabajo; Gustafson fija el tiempo de ejecución.

La nota de John Gustafson de 1988, Reevaluating Amdahl's law, informó aceleraciones de 1016 a 1021 en un hipercubo de 1024 procesadores en Sandia, para aplicaciones con una parte secuencial del 0,4 al 0,8 %, y defendió que los usuarios agrandan el problema hasta llenar el tiempo del que disponen. Con s' como la parte secuencial medida en la ejecución paralela, la aceleración escalada, una fórmula que la nota atribuye a E. Barsis en Sandia, es N + (1 − N)s'.

Con s' = 0,05 y 64 procesadores eso da 60,85, frente a 15,42 según Amdahl, porque los dos valores del 5 % se miden en máquinas distintas. En un sistema web, Gustafson encaja cuando cada servidor añadido trabaja con su propia parte de los datos; Amdahl encaja cuando cada usuario adicional sigue tocando la misma fila compartida.

¿Qué añade la Universal Scalability Law?

Un segundo término de coherencia, el coste de mantener coherentes los datos compartidos entre workers, que crece con el número de pares de workers. Con él, el rendimiento puede llegar a un máximo y luego caer a medida que añades capacidad.

El artículo de Gunther A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) formula la Universal Scalability Law (USL) así:

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ es la contención (serialización o colas) y κ la coherencia (copias incoherentes de los datos); con κ = 0 queda la fórmula de Amdahl. Entre los ejemplos de Gunther para el peor caso está la actualización de registros de bases de datos, y llama «retrograde», es decir, decreciente, al rendimiento más allá de N*. Con los valores de ejemplo σ = 0,05 y κ = 0,001, el máximo está cerca de 31 workers: el rendimiento relativo es 9,03 con 32 y 7,82 con 64, donde el término σ por sí solo predice 15,42.

¿Cómo ajustas la USL a una serie de pruebas de carga?

Mide el rendimiento en varios niveles de concurrencia, divide cada valor entre el rendimiento con un usuario y ajusta σ y κ por mínimos cuadrados.

Reordenada, la fórmula queda N / C − 1 = σ(N − 1) + κN(N − 1), que es lineal en σ y κ. Los valores de abajo se generaron a partir de σ = 0,05 y κ = 0,001; pon en x tus propias peticiones por segundo de cada escalón:

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

El script imprime sigma=0.050, kappa=0.0010 y un máximo cerca de 31 usuarios. Cambia solo la concurrencia entre escalones e incluye un escalón con un usuario, porque cada punto se divide entre él.

¿Dónde dejan de ser útiles estos modelos?

Resumen una curva de rendimiento en una o dos constantes, así que no pueden señalar el bloqueo culpable ni seguir a un sistema que cambia bajo carga. Úsalos para leer una curva medida y prolongarla un poco: un ajuste con escalones muy por debajo del codo dice poco del máximo.

Parámetros constantes. Una caché que se calienta, un autoscaler o un pool que llega a su límite cambian σ y κ en mitad de la prueba.
Solo rendimiento. El p95 y el p99 pueden degradarse antes: revisa también la latencia de cola.
El generador de carga. Si se satura primero, la curva plana es suya.
Pruebas cerradas. Un número fijo de usuarios virtuales mide un sistema cerrado; los usuarios reales llegan a su propio ritmo.

FAQ

¿Puedes explicar la ley de Amdahl de forma sencilla? Un trabajo nunca es más rápido que la parte que no se puede repartir. Si una décima parte del trabajo tiene que ejecutarse en serie, ningún número de workers adicionales lo hace más de diez veces más rápido, porque esa décima parte sigue tardando lo mismo.

¿Qué es la ley de Gustafson? La ley de Gustafson dice que, cuando el problema crece con el número de procesadores, la aceleración crece casi de forma lineal, como N + (1 − N)s', donde s' es la parte secuencial de la ejecución paralela. John Gustafson la publicó en 1988 (atribuyendo la fórmula a su colega de Sandia E. Barsis) como contrapunto a la suposición de Amdahl de un problema de tamaño fijo.

Lecturas relacionadas

Teoría de colas: qué es y por qué se dispara la latencia

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

La teoría de colas (en inglés queueing theory) es la matemática de las esperas: a partir del ritmo al que llega el trabajo, de lo que tarda cada tarea y del número de servidores, predice cuánto esperan las tareas y cuánto crece la cola. Para el software, su resultado más útil es que el tiempo de respuesta crece despacio con carga moderada y luego de golpe cuando un servidor se acerca al 100 % de ocupación. En el modelo más sencillo, un servidor ocupado el 90 % del tiempo responde de media diez veces más lento que uno libre.

Las cifras de abajo son aritmética a partir de fórmulas estándar, comprobadas con un script, sin ninguna prueba detrás. Las fuentes se comprobaron el 1 de noviembre de 2026.

Utilización ρ	Tiempo en el sistema W ÷ tiempo de servicio S	Si S = 20 ms
0,5	2	40 ms
0,7	3,3	67 ms
0,8	5	100 ms
0,9	10	200 ms
0,95	20	400 ms
0,99	100	2.000 ms

Son medias para la cola M/M/1: un servidor, llegadas de Poisson y tiempos de servicio exponenciales.

¿Qué es la teoría de colas?

Es la rama de la probabilidad que modela trabajo que llega, espera y se atiende. Una cola se describe por sus llegadas, sus tiempos de servicio, su número de servidores y su disciplina de cola, es decir, el orden en que se atienden las tareas en espera.

Urban Operations Research, de Larson y Odoni, un texto abierto del MIT, cita las ventanillas de banco, las cajas de supermercado y los peajes como casos clásicos. Un servidor web encaja en el mismo esquema: llegan peticiones, los hilos o núcleos las atienden y el resto espera en una cola.

¿De dónde viene la teoría de colas?

De la central telefónica, donde A. K. Erlang obtuvo los primeros resultados para la Compañía Telefónica de Copenhague.

Según su biografía en MacTutor, el artículo de Erlang de 1909 mostró que las llamadas hechas al azar siguen la distribución de Poisson, y su fórmula de 1917 para las pérdidas y el tiempo de espera pronto la usaron compañías telefónicas de muchos países. El artículo de David Kendall de 1953, Stochastic Processes Occurring in the Theory of Queues and their Analysis by the Method of the Imbedded Markov Chain, introdujo la notación que aún se usa, como recoge el relato de su obra de Geoffrey Grimmett. La demostración de L = λW de Little y los resultados de Kingman sobre tráfico intenso llegaron en 1961.

¿Qué significa la notación de Kendall, como M/M/1?

Nombra una cola en tres partes, A/S/c: la distribución de los intervalos entre llegadas, la de los tiempos de servicio y el número de servidores. M/M/1 significa llegadas aleatorias, tiempos de servicio exponenciales y un servidor.

M viene de memoryless, sin memoria (llegadas de Poisson o tiempos exponenciales), D de determinista y G de general, es decir, cualquier distribución: M/D/1 es un servidor con tiempo de servicio constante.

¿Cómo crece el tiempo de respuesta con la utilización?

En una cola M/M/1, el tiempo medio en el sistema es W = 1/(μ − λ), que equivale a S/(1 − ρ). Cuando la utilización ρ se acerca a 1, W crece sin límite.

lambda = arrival rate        mu = service rate (1 / S)
rho    = lambda / mu         (utilization, must stay below 1)
W      = 1 / (mu - lambda)   = S / (1 - rho)

Larson y Odoni lo deducen para una centralita con una sola operadora y muestran que con ρ ≥ 1 no hay estado estacionario: la cola no deja de crecer. La misma fuente muestra que el tiempo en el sistema sigue una distribución exponencial, así que cada percentil crece por el mismo factor 1/(1 − ρ), y el p95 ronda el triple de la media: 600 ms en la fila 0,9 de arriba.

¿Por qué la latencia hace un codo antes de que la CPU llegue al 100 %?

Porque una petición espera cada vez que encuentra el servidor ocupado, y eso ocurre más a menudo a medida que sube la utilización. Con los supuestos de M/M/1, el tiempo de respuesta ya se ha duplicado al 50 % de utilización.

El recurso que se satura también puede ser un pool de conexiones, un bloqueo de la base de datos o un bucle de eventos de un solo hilo, y el más cargado marca la curva. Ese codo temprano explica por qué la utilización objetivo queda muy por debajo del 100 %. Calcula hacia atrás desde tu presupuesto de latencia: con S = 20 ms y una media objetivo de 100 ms, la tabla permite alrededor del 80 %, y un objetivo de 60 ms alrededor del 67 %, antes de que los picos se lleven su parte.

El panel de capacidad de LoadFocus agrupa una prueba terminada por el número de usuarios virtuales activos e indica el último nivel que aguantó antes de que la tasa de errores superara el 1 % o el p95 pasara del doble del mejor nivel, siempre que ningún nivel superior se recuperara. Necesita una prueba con un solo generador de carga que suba por al menos tres escalones de carga, con el más alto al menos al doble del más bajo. Según la cuenta de arriba, si el nivel más ligero dejó el cuello de botella casi inactivo, la duplicación salta justo por encima del 50 % de utilización; si ya lo cargaba hasta ρ0, salta más tarde, por encima de (1 + ρ0)/2 con M/M/1.

¿Por qué la variabilidad importa tanto como la utilización?

Las colas nacen del azar: llegadas en ráfagas y tareas lentas de vez en cuando. Con tráfico intenso, el tiempo de espera crece con la variabilidad de ambas, multiplicada por un término ρ/(1 − ρ).

El artículo de Kingman de 1961, The single server queue in heavy traffic, muestra que cuando la intensidad de tráfico de un servidor único se acerca a 1, la cola es larga y el tiempo de espera es aproximadamente exponencial. Apuntes de curso de la TU Eindhoven y del Technion dan una aproximación para su media (el Technion la llama aproximación de Allen-Cunneen; también se conoce ampliamente como fórmula de Kingman):

Wq ≈ rho / (1 - rho) × (ca² + cs²) / 2 × S
ca, cs = coefficient of variation (std dev / mean)
         of arrival gaps and of service times

Wq es la espera antes de que empiece el servicio, y ca, cs son los coeficientes de variación. Los tiempos exponenciales tienen c² = 1, lo que da la espera de M/M/1 de 9S al 90 % de utilización. Un tiempo de servicio constante la reduce a la mitad, 4,5S; con cs² = 4, lo que puede producir una mezcla de aciertos de caché y llamadas lentas a la base de datos, sube a 22,5S. El tráfico sintético regular varía menos que el de producción, así que una prueba suele mostrar menos cola que los picos reales.

¿Cómo ayudan más servidores (M/M/c)?

Varios servidores que comparten una cola absorben las ráfagas aleatorias mucho mejor que los mismos servidores con una cola cada uno, así que cada servidor puede trabajar con más carga para la misma espera.

Según las fórmulas M/M/m de Larson y Odoni, con cada servidor ocupado al 90 %, W es 10S con un servidor, 5,3S con dos que comparten cola y 3,0S con cuatro. Cuatro instancias detrás de un balanceador que elige una libre se comportan como el último caso; cuatro que reciben cada una un cuarto aleatorio del tráfico, como colas M/M/1 separadas a 10S.

¿Qué tiene que ver la ley de Little?

La ley de Little, L = λW, relaciona el número medio de peticiones en un sistema con su tasa de llegada y su tiempo dentro, sean cuales sean las distribuciones. La teoría de colas te da W, y la ley de Little lo convierte en L.

En la fila 0,9, 45 peticiones por segundo con W = 200 ms suponen de media 9 peticiones dentro. Nuestro artículo sobre la ley de Little usa la misma ley para dimensionar y comprobar pruebas de carga.

¿Dónde dejan de valer estos modelos en las pruebas de carga?

Suponen un flujo abierto de llegadas independientes y un estado estacionario. Una prueba con un número fijo de usuarios virtuales es un sistema cerrado, donde las llegadas se frenan cuando se frenan las respuestas.

Pruebas cerradas. Con N usuarios virtuales hay como mucho N peticiones en el sistema, así que el ritmo de peticiones cae donde una cola abierta crecería, y el tiempo de reflexión lo baja aún más. Nuestro artículo sobre el modelo de carga abierto vs cerrado explica por qué eso oculta la saturación.
LoadFocus ejecuta scripts de k6, pero los escenarios arrival-rate se ejecutan allí con un número fijo de usuarios, como avisa su validador de scripts. Lee esas pruebas como cerradas: pasado el codo, espera un ritmo de peticiones plano y tiempos de respuesta en aumento.
Estado estacionario. El calentamiento, las cachés y el autoescalado cambian la tasa de servicio durante la prueba, así que compara niveles mantenidos el tiempo suficiente para estabilizarse.

FAQ

¿Se escribe queueing theory o queuing theory? Las dos grafías inglesas son correctas y nombran el mismo campo. El artículo de Kingman de 1961 escribe «queueing time», mientras que la demostración de Little del mismo año lleva «Queuing Formula» en el título.

¿La teoría de colas necesita llegadas de Poisson? Solo para los resultados exactos de M/M/1. Las aproximaciones G/G/1 como la fórmula de Kingman usan la media y la variabilidad de los intervalos entre llegadas y de los tiempos de servicio, y la ley de Little no supone nada sobre las distribuciones.

Lecturas relacionadas

SLO vs SLA: diferencia, SLI y presupuesto de error

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Un SLA (acuerdo de nivel de servicio) es un contrato con un cliente que dice qué pasa cuando un servicio no alcanza un nivel prometido, normalmente un crédito de servicio. Un SLO (objetivo de nivel de servicio) es la meta interna con la que un equipo gestiona el servicio; el libro de SRE aconseja fijarla más estricta que el SLA para que los problemas se resuelvan antes de incumplir el contrato. Un SLI (indicador de nivel de servicio) es la medida en la que se expresan ambos, por ejemplo la proporción de peticiones que tienen éxito.

	SLI	SLO	SLA
Qué es	Una medida	Una meta para un SLI	Un contrato basado en SLO
Lo fija	Ingeniería	El product owner e ingeniería	Los equipos de negocio y legal
Si se incumple	Nada por sí solo	Se gasta presupuesto de error	Créditos de servicio o penalizaciones
Ejemplo	Llamadas de pago con éxito	99,95 % en cuatro semanas	99,9 % al mes, o un crédito

Los ejemplos son ilustrativos; las fuentes son el libro y el workbook de SRE de Google y el SLA de cómputo de AWS, comprobados el 1 de noviembre de 2026.

¿Qué significan SLI, SLO y SLA?

Service level indicator, service level objective y service level agreement: indicador, objetivo y acuerdo de nivel de servicio. El indicador es lo que mides, el objetivo es el valor al que apuntas y el acuerdo es lo que prometes a otra persona, con consecuencias.

El capítulo «Service Level Objectives» del libro de SRE define un SLA como «un contrato explícito o implícito con tus usuarios que incluye consecuencias por cumplir (o incumplir) los SLO que contiene». La prueba del capítulo es una sola pregunta: ¿qué pasa si no se cumplen los SLO? Si no hay una consecuencia explícita, casi seguro que estás ante un SLO.

El capítulo añade que la mayoría de la gente quiere decir SLO cuando dice SLA, y que una violación real de un SLA puede acabar en un pleito por incumplimiento de contrato. Así que, cuando una reunión se convierte en una discusión de SLA vs SLO, pregunta primero si hay una consecuencia, normalmente dinero, escrita en un contrato.

El libro de SRE aconseja mantener un margen de seguridad: «un SLO interno más estricto que el SLO anunciado a los usuarios te da espacio para responder a problemas crónicos antes de que se vean desde fuera». Su capítulo «Embracing Risk» aplica la misma idea a un contrato: un objetivo externo del 99,9 % respaldado por uno interno más exigente.

¿Qué es un presupuesto de error?

Es el 100 % menos el SLO: la parte de las peticiones o del tiempo que puede fallar dentro de la ventana. Mientras quede presupuesto, el equipo sigue publicando cambios; cuando se agota, el trabajo de fiabilidad va primero.

El capítulo «Implementing SLOs» del workbook de SRE hace la cuenta: con un SLO del 99,9 %, un servicio que recibe 3 millones de peticiones en cuatro semanas puede fallar 3.000, así que una caída con 1.500 errores gasta la mitad del presupuesto. El capítulo «Embracing Risk» del libro explica para qué sirve: la gestión de producto fija el SLO, la monitorización mide la disponibilidad real y la diferencia es el margen de falta de fiabilidad que queda para el trimestre. Cuando ese presupuesto se agota, los despliegues se detienen o se ralentizan.

¿Cuánto tiempo de inactividad permite el 99,9 %?

Unos 43 minutos en una ventana de 30 días. Cada nueve adicional divide el margen entre diez, así que el 99,99 % deja poco más de 4 minutos.

SLO	Presupuesto de error	Inactividad en 30 días	Fallos por millón
99 %	1 %	7 h 12 min	10.000
99,5 %	0,5 %	3 h 36 min	5.000
99,9 %	0,1 %	43 min 12 s	1.000
99,95 %	0,05 %	21 min 36 s	500
99,99 %	0,01 %	4 min 19 s	100

Multiplica los 43.200 minutos de una ventana de 30 días por el presupuesto de error. Ten en cuenta la advertencia del workbook: cada nueve adicional cuesta más mientras su valor para los usuarios tiende a cero.

¿Cómo es un SLA real?

Indica un porcentaje medido, un periodo de facturación, una escala de créditos y lo que no cuenta. El SLA de cómputo de AWS es un ejemplo público y breve.

El Amazon Compute Service Level Agreement (actualizado el 25 de mayo de 2022; comprobado el 1 de noviembre de 2026) se compromete a un Monthly Uptime Percentage de al menos el 99,99 % por región para instancias EC2 repartidas en dos o más Availability Zones, y del 99,5 % para una sola instancia. La disponibilidad es el 100 % menos la parte de los minutos en que EC2 no estuvo disponible. Según el Region-Level SLA, por debajo del 99,99 % el crédito es el 10 % de la factura mensual de EC2 en la región, por debajo del 99,0 % es el 30 % y por debajo del 95,0 % es el 100 %; para una sola instancia, el tramo del 10 % empieza por debajo del 99,5 %. Los créditos se aplican a pagos futuros, hay que reclamarlos a través del soporte de AWS y son el recurso «único y exclusivo», salvo que el acuerdo con el cliente diga otra cosa.

Comparado con la tabla de inactividad, el tramo del 10 % del Region-Level SLA abarca de unos 4 minutos a unas 7 horas de indisponibilidad en un mes de 30 días. Un SLA limita lo que debe el proveedor; evitar que las caídas perjudiquen a tus usuarios es tarea de tus propios objetivos.

¿Cómo eliges SLI de latencia y de disponibilidad?

Mide la latencia como percentil y la disponibilidad como eventos buenos divididos entre todos los eventos, lo más cerca posible del usuario. Las medias y las cifras tomadas solo en el servidor esconden las peticiones de las que se queja la gente.

Latencia. El libro de SRE prefiere los percentiles a la media, porque una media puede quedarse plana mientras las peticiones más lentas se vuelven mucho más lentas. El workbook escribe los SLI de latencia como un cociente, por ejemplo las llamadas que terminan en menos de 100 ms divididas entre todas las llamadas. Así que «el 99 % de las llamadas de pago en menos de 400 ms» equivale a «p99 del pago por debajo de 400 ms» en la ventana, y pasa tal cual a una prueba. Nuestro artículo sobre la latencia de cola explica por qué el p99 importa en cuanto una página llama a varios servicios.

Disponibilidad. La disponibilidad por tiempo cuenta los minutos en funcionamiento, como hace el SLA de AWS. La disponibilidad por peticiones cuenta las peticiones con éxito: «Embracing Risk» describe un servicio con 2,5 millones de peticiones al día y un objetivo diario del 99,99 %, que puede devolver 250 errores y aun así cumplirlo.

¿Dónde fallan los SLO?

Casi siempre por exceso de objetivos, por metas del 100 % y por indicadores medidos donde no están los usuarios. Cada uno deja una cifra sobre la que nadie actúa, o una que parece buena mientras los usuarios lo pasan mal.

Demasiados SLO. El libro de SRE aconseja tener los menos posibles: si citar un SLO nunca sirve para ganar una discusión sobre prioridades, probablemente no merece la pena.
Metas del 100 %. El workbook dice que el 100 % es la meta equivocada: los componentes fallan, los cambios son la principal causa de caídas y un SLO del 100 % solo deja tiempo para reaccionar.
Medir solo en el servidor. Las métricas del servidor no ven problemas que sí notan los usuarios, como un script lento en la página. El workbook propone medir en el balanceador de carga o en el cliente.

¿Qué tienen que ver las pruebas de carga con los SLO?

Un SLO le da a una prueba de carga sus criterios de aprobación, y una prueba en el pico esperado muestra si el SLO de latencia aguanta antes de que llegue ese tráfico. La monitorización en producción solo te lo dice después.

El libro de SRE señala que más peticiones por segundo (QPS) suelen traer latencias mayores y que es habitual que los servicios tengan un precipicio de rendimiento a partir de cierto umbral de carga. Una prueba de carga puede encontrar ese precipicio si se ejecuta en el pico esperado, con una mezcla realista de peticiones, y mide el mismo SLI que usa el SLO. Fija cada umbral de la prueba un poco más estricto que el SLO, como explica nuestra guía de criterios de aprobación en pruebas de carga. Una ejecución dura minutos, así que no puede medir la disponibilidad mensual.

LoadFocus, que publica este sitio, evalúa las pruebas de carga con umbrales de aprobación guardados en la prueba: Max P95 y Max P99 del tiempo de respuesta, una tasa de errores máxima y un rendimiento mínimo, para pruebas cloud, JMeter y k6. Su monitorización de API ofrece informes de SLA y SLO que fijan un objetivo SLO por monitor y muestran la disponibilidad, el presupuesto de error consumido y un estado OK o Incumplido.

FAQ

¿Qué significa SLO? Service level objective, u objetivo de nivel de servicio: un valor meta para un nivel de servicio medido, por ejemplo el 99,9 % de peticiones con éxito en cuatro semanas. Se fija internamente, entre producto e ingeniería, y por sí solo no conlleva ninguna penalización contractual.

¿Se puede tener un SLO sin un SLA? Sí. El libro de SRE pone como ejemplo la búsqueda de Google, un servicio importante sin SLA público que aun así se gestiona con SLI y SLO.

¿Debería un SLO ser alguna vez del 100 %? No. Un objetivo del 100 % no deja presupuesto de error, así que cualquier fallo lo incumple y ningún cambio es nunca seguro de publicar.

Lecturas relacionadas

TPC-H: qué mide el benchmark y cómo ejecutarlo

Sun, 01 Nov 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

TPC-H es el benchmark de soporte a la decisión del Transaction Processing Performance Council (TPC): 22 consultas de negocio y dos funciones de actualización se ejecutan sobre ocho tablas que el programa dbgen del TPC llena con un factor de escala elegido, donde el factor 1 equivale a aproximadamente 1 GB. Su métrica, QphH@Size, combina una prueba de potencia con un solo flujo y una prueba de throughput con varios flujos, y los resultados oficiales añaden un precio por kQphH@Size. Solo los resultados auditados publicados en tpc.org son oficiales; cualquier cifra tipo TPC-H publicada fuera de tpc.org cuenta como una carga derivada según las reglas de uso justo del TPC y no está permitido compararla con los resultados oficiales.

No hemos ejecutado el benchmark para esta guía. Los datos proceden de tpc.org, de la especificación en su revisión 3.0.1, que tpc.org marca como actual, y de la documentación de cada herramienta, todo comprobado el 1 de noviembre de 2026. Las valoraciones son nuestras.

	TPC-H	TPC-C	TPC-DS
Carga	Soporte a la decisión: consultas ad hoc más actualizaciones de datos	OLTP: los pedidos de un mayorista	Soporte a la decisión: consultas más mantenimiento de datos
Alcance	8 tablas, 22 consultas, 2 funciones de actualización	9 tipos de tablas, 5 tipos de transacciones	Esquema en copo de nieve, 7 tablas de hechos, 99 consultas
Métrica principal	QphH@Size y $/kQphH@Size	tpmC	QphDS@SF y $/kQphDS@SF
Versión actual	3.0.1	5.11.0	4.0.0

¿Qué mide TPC-H?

La rapidez con la que un sistema responde a consultas analíticas complejas sobre un gran volumen de datos mientras llegan ventas nuevas y se borran las antiguas. Una sola especificación define el esquema, las consultas, los datos y las reglas.

La página de TPC-H describe un conjunto de consultas ad hoc orientadas al negocio junto con modificaciones de datos simultáneas (comprobado el 1 de noviembre de 2026). La especificación define ocho tablas: PART, PARTSUPP, LINEITEM, ORDERS, CUSTOMER, SUPPLIER, NATION y REGION. Todas salvo las dos últimas crecen con el factor de escala; LINEITEM, la mayor, tiene unos 6.000.000 de filas por unidad. La función de actualización RF1 inserta filas nuevas en ORDERS y LINEITEM, y RF2 elimina ventas antiguas (comprobado el 1 de noviembre de 2026).

¿Cómo se calcula la puntuación de TPC-H?

Una ejecución es una prueba de potencia seguida de una prueba de throughput, y QphH@Size es la media geométrica de ambos resultados. La métrica de precio es el precio total del sistema dividido por QphH@Size, multiplicado por 1.000.

En la prueba de potencia, un flujo de actualización ejecuta RF1, una única sesión de consultas ejecuta las 22 consultas una vez y luego el flujo de actualización ejecuta RF2. Power@Size es 3.600 por el factor de escala, dividido por la media geométrica de esos 24 tiempos. En la prueba de throughput, varios flujos de consultas corren junto a un flujo de actualización: al menos 2 con factor 1 y hasta 11 con factor 100.000. Throughput@Size son las consultas por hora de todos los flujos, multiplicadas por el factor de escala. Una prueba completa tiene dos ejecuciones, y el patrocinador informa de la que tiene el QphH más bajo (todo según la especificación, comprobado el 1 de noviembre de 2026).

La media geométrica da a cada consulta el mismo peso, así que reducir a la mitad el tiempo de una sola consulta sube Power solo un 3 % aproximadamente. Un resultado oficial usa un factor de escala de una lista fija: 1, 10, 30, 100 y así hasta 100.000.

¿Quién publica resultados de TPC-H y cuáles cuentan?

Los fabricantes que patrocinan una prueba publican resultados auditados en tpc.org, y solo esos son oficiales. Cualquier otra ejecución es una carga derivada con sus propias reglas.

La especificación exige una auditoría independiente a cargo de un auditor certificado por el TPC. La referencia rápida de uso justo (fair use) del TPC solo permite el nombre del TPC junto a resultados oficiales publicados. Todo lo demás necesita el prefijo «Derived from», no puede usar la métrica del TPC, debe incluir un aviso de que no es comparable con los resultados publicados, debería describir su entorno y sus desviaciones y no puede compararse con resultados oficiales (comprobado el 1 de noviembre de 2026).

¿Cómo ejecutas TPC-H por tu cuenta?

Genera los datos y el texto de las consultas, carga las tablas y luego ejecuta la prueba de potencia seguida de la de throughput. Puedes usar las herramientas del TPC, un kit hecho para una base de datos concreta o un motor con generador integrado.

La página de especificaciones actuales del TPC ofrece un paquete de herramientas gratuito: te registras, aceptas una licencia y recibes el enlace por correo. Según la especificación, DBGen debe producir los datos y QGen el texto de las consultas (comprobado el 1 de noviembre de 2026).

Para PostgreSQL, la página TPC-H de la wiki no da un procedimiento paso a paso y remite a DBT-3, un kit completo que la página DBT-3 de la wiki describe como una implementación de la especificación conforme al uso justo. HammerDB incluye TPROC-H, que su documentación describe como una carga de código abierto derivada de TPC-H y no comparable con los resultados publicados. Funciona sobre PostgreSQL, MySQL, Oracle y otros motores, y la documentación recomienda comparar la media geométrica de los tiempos de consulta en lugar de calcular un QphH (todo comprobado el 1 de noviembre de 2026).

DuckDB tiene una extensión tpch que, según su documentación, implementa el generador de datos y las consultas. Estas líneas generan el factor 1, ejecutan la consulta 4 y listan las 22 consultas:

CALL dbgen(sf = 1);
PRAGMA tpch(4);
FROM tpch_queries();

La misma página advierte de que los datos difieren un poco de la especificación, de que cada consulta se ejecuta con parámetros fijos y de que dbgen no borra las tablas existentes. Para datos totalmente conformes remite a tpchgen-cli (comprobado el 1 de noviembre de 2026).

¿Cómo lees con honestidad los resultados de TPC-H?

Compara resultados solo con el mismo factor de escala y la misma versión del benchmark, y lee cada métrica con su sufijo de tamaño. Un gráfico de tiempos de consultas sueltas no muestra ni la prueba de potencia ni la de throughput.

La página de resultados agrupa los resultados por tamaño de base de datos y lleva tres notas: los resultados de las versiones 2 y 3 no son comparables, la relación precio/rendimiento en monedas distintas no debe compararse y las comparaciones entre tamaños de base de datos son engañosas (comprobado el 1 de noviembre de 2026). La especificación añade que los resultados con distinto número de flujos son comparables con el mismo tamaño de base de datos.

En una ejecución informal, busca lo que piden las reglas de uso justo: hardware y memoria, cambios en el esquema o en el texto de las consultas y si se ejecutaron las funciones de actualización. Un artículo que mide las 22 consultas una vez, con la caché caliente y sin flujo de actualización, solo se aproxima a la parte de consultas de una prueba de potencia, aunque una ejecución así sigue siendo útil para controlar tus propias regresiones. Sobre el ritmo de consultas frente al tiempo de respuesta, consulta rendimiento vs latencia.

¿Cuándo conviene usar algo distinto de TPC-H?

Cuando la carga es transaccional, cuando quieres un benchmark analítico más reciente o cuando la pregunta es qué notan los usuarios. El benchmark modela una carga analítica, sin transacciones cortas ni capa de aplicación.

Elige TPC-DS para una prueba de soporte a la decisión más amplia: su especificación en la versión 4.0.0 usa un esquema en copo de nieve con siete tablas de hechos y 99 consultas, y su página de presentación indica que los resultados de la versión 4 no son comparables con versiones anteriores. Elige TPC-C, o el TPROC-C de HammerDB, para OLTP de entrada de pedidos: la página de TPC-C describe cinco tipos de transacciones medidos en tpmC (todo comprobado el 1 de noviembre de 2026). Para una comprobación rápida de una sola base de datos, pgbench cubre PostgreSQL y sysbench cubre MySQL.

LoadFocus, que publica este sitio, no ejecuta TPC-H; sus pruebas se dirigen a endpoints web y de API. LoadFocus ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube, sin driver JDBC ni módulo SQL, así que no puede conectarse a la base de datos. Para este trabajo, elige una herramienta de benchmark de bases de datos como la extensión de DuckDB, DBT-3 o HammerDB en lugar de LoadFocus, y usa LoadFocus para la capa web o API que va delante de la base de datos.

FAQ

¿Qué diferencia hay entre TPC-H y TPC-DS? Los dos son benchmarks de soporte a la decisión del TPC. TPC-H usa 8 tablas y 22 consultas e informa de QphH@Size, mientras que TPC-DS usa un esquema en copo de nieve con siete tablas de hechos y 99 consultas e informa de QphDS@SF.

¿Qué significa QphH@Size en TPC-H? Es la métrica compuesta de consultas por hora: la media geométrica de los resultados de la prueba de potencia y de la prueba de throughput con un tamaño de base de datos. El sufijo indica ese tamaño, por ejemplo QphH@1000GB, y los resultados con tamaños distintos no deben compararse.

¿Puede LoadFocus ejecutar TPC-H? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6 dirigidos a endpoints web y de API y no tiene conexión SQL, así que usa una herramienta de benchmark de bases de datos para TPC-H y LoadFocus para la capa de aplicación que va delante de la base de datos.

Lecturas relacionadas

pgbench: benchmark y pruebas de carga de PostgreSQL

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

pgbench es el programa de benchmark que viene con PostgreSQL: ejecuta la misma transacción SQL una y otra vez en varias sesiones de base de datos simultáneas e informa de las transacciones por segundo y la latencia. Creas sus tablas de prueba con pgbench -i -s 50 mydb y luego lanzas algo como pgbench -c 10 -j 2 -T 300 mydb para diez clientes en dos hilos durante cinco minutos. Mide solo la base de datos, así que no dice nada de lo que notan los usuarios a través de la aplicación que va delante.

No hemos ejecutado pgbench para esta guía. Los datos salen de la página de pgbench en la documentación de PostgreSQL 18, la versión que postgresql.org marca como actual, comprobados el 31 de octubre de 2026, y las valoraciones son nuestras.

Opción	Qué hace
`-i` / `-s`	Crear las tablas de prueba / factor de escala (100.000 cuentas por unidad)
`-c`	Clientes, es decir, sesiones de base de datos simultáneas (1 por defecto)
`-j`	Hilos de trabajo dentro de pgbench (1 por defecto)
`-T` / `-t`	Duración en segundos, o transacciones por cliente (10 por defecto)
`-b` / `-f`	Un script integrado o un archivo tuyo, con un `@peso` opcional
`-P`	Informe de progreso cada N segundos
`-R` / `-L`	Ritmo objetivo en tps / límite de latencia en ms
`-r` / `-l`	Latencias por sentencia / una línea de registro por transacción

¿Qué mide pgbench?

Ejecuta un script de transacción una y otra vez en un número fijo de sesiones de base de datos e informa de la tasa media de transacciones y de la latencia. El script por defecto se basa de forma libre en el benchmark bancario TPC-B.

Según la documentación de pgbench, el escenario por defecto se inspira en TPC-B sin ser realmente TPC-B, y de ahí su nombre: la salida lo llama TPC-B (sort of) (comprobado el 31 de octubre de 2026).

¿Cómo se prepara una base de datos para pgbench?

Ejecuta pgbench -i contra una base de datos existente, con -s para el factor de escala. El comando crea cuatro tablas y borra cualquier tabla existente con el mismo nombre, así que dale una base de datos propia.

Con factor 1, pgbench_branches tiene una fila, pgbench_tellers 10, pgbench_accounts 100.000 y pgbench_history ninguna, y -s multiplica esas filas: -s 100 da 10.000.000 de filas en pgbench_accounts. La documentación no indica el tamaño en disco, así que mídelo después de inicializar (comprobado el 31 de octubre de 2026).

¿Qué scripts integrados trae pgbench?

Tres: tpcb-like (el predeterminado), simple-update y select-only. Eliges uno con -b o con los atajos -N y -S.

El predeterminado envía siete comandos por transacción: BEGIN, un update y un select sobre una cuenta al azar, updates sobre pgbench_tellers y pgbench_branches, un insert en pgbench_history y END. simple-update quita los dos updates sobre las tablas pequeñas, con lo que evita la contención en ellas y, según la documentación, aleja todavía más la prueba de TPC-B. select-only solo envía el select.

¿Cómo se escribe un script propio de pgbench?

Pon tu SQL en un archivo, define variables con \set y las funciones aleatorias, y pasa el archivo con -f. Cada ejecución del archivo cuenta como una transacción.

\set aid random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta
  WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
END;

Un peso después de @ fija la frecuencia con la que se elige cada script: -f update.sql@9 -b select-only@1 elige el archivo unas nueve de cada diez veces. La documentación también recoge random_exponential, random_gaussian y random_zipfian, con las que puedes concentrar el acceso en unas pocas filas. \sleep añade una pausa, la versión de base de datos del tiempo de reflexión. Si solo ejecutas tus propios archivos, pasa el factor de escala de la base de datos con -s; si no, :scale se queda en 1 y el script de arriba solo toca las primeras 100.000 cuentas. Con tus propias tablas, omite -i y añade -n para que pgbench no haga VACUUM de las tablas estándar (comprobado el 31 de octubre de 2026).

¿Qué opciones convierten pgbench en una prueba de carga?

La concurrencia sale de -c y -j, la duración de -T y la forma de la carga de -R. Sin -R, cada cliente lanza su siguiente transacción en cuanto termina la anterior.

Ese comportamiento por defecto es un modelo de carga cerrado, como explica nuestro artículo sobre el modelo de carga abierto vs cerrado. Con -R, pgbench lanza las transacciones según un calendario con distribución de Poisson que avanza desde el arranque del cliente, pase lo que pase con las transacciones anteriores. La latencia que muestra cuenta entonces desde cada inicio previsto e incluye el retraso sobre el calendario (schedule lag), cuya media y máximo aparecen por separado: es la corrección que describe nuestro artículo sobre coordinated omission. El número de clientes no cambia, así que si el retraso no deja de crecer, el sistema no aguanta ese ritmo con los clientes e hilos elegidos: baja -R o añade clientes.

--latency-limit (-L) cuenta como tardías las transacciones que superan un límite en milisegundos; con -R, pgbench además se salta las transacciones que ya van demasiado retrasadas y las cuenta como omitidas. -M prepared usa sentencias preparadas, más rápidas que los otros modos según la documentación (comprobado el 31 de octubre de 2026).

¿Cómo se lee la salida de pgbench?

El resumen muestra la configuración, las transacciones procesadas y fallidas, la latencia media, el tiempo de conexión inicial y los tps. Esta forma sale de la documentación, sin las cifras:

transaction type: <builtin: TPC-B (sort of)>
number of transactions actually processed: ...
number of failed transactions: ... (...%)
latency average = ... ms
latency stddev = ... ms   (only with -P, -R or -L)
initial connection time = ... ms
tps = ... (without initial connection time)

Las transacciones fallidas son errores de serialización o deadlocks, que --max-tries puede reintentar. Los demás errores SQL abortan el cliente afectado y dejan un código de salida 2. El resumen no trae percentiles: para la latencia de cola, registra cada transacción con -l, que guarda su duración en microsegundos, y calcula tú el p95 o el p99.

Sin -P, -R ni -L, la latencia media del resumen no se mide: pgbench la deduce a partir de la duración y del número de clientes, es decir, la ley de Little aplicada al revés, con los fallos incluidos. Añade -P cuando importe la latencia.

¿Cómo se consiguen cifras de pgbench fiables?

Haz que cada ejecución dure varios minutos, repítela, mantén el factor de escala al menos igual al número de clientes y vigila el VACUUM. Si el propio pgbench se convierte en el cuello de botella, llévalo a otra máquina.

La primera pauta de la sección «Good Practices» de la documentación advierte que no te fíes de ninguna prueba que dure solo unos segundos, y añade que unas cifras reproducibles pueden requerir horas (comprobado el 31 de octubre de 2026). Con el script por defecto, un factor de escala menor que el número de clientes mide sobre todo la contención de los updates, porque pgbench_branches solo tiene -s filas y cada transacción modifica una. Las filas muertas y el autovacuum cambian los resultados de una ejecución a otra. Con muchas sesiones, pgbench puede saturar su propia máquina: ejecútalo en una máquina aparte con baja latencia de red, o reparte varias instancias entre varias máquinas.

¿Cuándo no es pgbench la herramienta adecuada?

Cuando la pregunta trata de los usuarios, de otra base de datos o de una mezcla OLTP estándar. pgbench mide PostgreSQL a solas, sin tu pool de conexiones, tu ORM, tu caché ni tu capa HTTP.

Para ver lo que notan los usuarios, pon carga en la capa HTTP o API que va delante. LoadFocus, que publica este sitio, no ejecuta pgbench ni puede conectarse directamente a PostgreSQL: ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra endpoints web y de API.

Elige sysbench para MySQL: su repositorio describe una herramienta de benchmark programable y multihilo con pruebas de base de datos de tipo OLTP. Elige HammerDB para una mezcla al estilo de TPC-C: su documentación describe TPROC-C, una carga derivada de TPC-C, que ejecuta sobre PostgreSQL y otros motores. Elige JMeter con su sampler JDBC Request para mezclar SQL y HTTP en un mismo plan de prueba en tus propias máquinas (todo comprobado el 31 de octubre de 2026).

FAQ

¿Para qué sirve la opción -s de pgbench? Fija el factor de escala al inicializar. Cada unidad añade 100.000 filas a pgbench_accounts, así que -s 100 crea 10.000.000 de filas. Con el script por defecto, mantenlo al menos igual a tu número de clientes.

¿Qué diferencia hay entre -c y -j en pgbench? La opción -c fija el número de clientes simulados, cada uno una sesión de base de datos simultánea. La opción -j fija cuántos hilos de trabajo de pgbench se reparten esos clientes.

¿Puede LoadFocus ejecutar pgbench? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6 y no tiene conexión directa con PostgreSQL, así que con él pones carga en la capa web o API que va delante de la base de datos.

Lecturas relacionadas

redis-benchmark: cómo usarlo y leer sus resultados

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

redis-benchmark es la utilidad de benchmark que viene con Redis: abre un número de conexiones de cliente (50 por defecto), envía un número fijo de comandos (100.000 por defecto) e informa, para cada prueba, de las peticiones por segundo y la latencia. Lanza redis-benchmark -q -n 100000 contra un servidor en marcha, limítalo con -t a los comandos que te interesan y lee el resultado como la velocidad de una sola instancia de Redis con comandos sintéticos. Tu aplicación añade su propio camino de red, su biblioteca cliente y su mezcla de comandos, así que espera otras cifras.

Lo ejecutamos el 31 de octubre de 2026 en un portátil Apple M1 Max, con servidor y cliente Redis 7.2.6 en la misma máquina por loopback y sin persistencia. Cada fila es una ejecución de 100.000 peticiones, con las peticiones por segundo redondeadas al millar; el p50 aparece tal como lo imprimió la herramienta.

Ejecución	Qué cambia	Peticiones por segundo	p50 (ms)
`-t set,get`	Nada: 50 clientes, valores de 3 bytes	SET 113.000, GET 118.000	0,367; 0,351
`-t set,get -P 16`	16 comandos por ida y vuelta	SET 1.010.000, GET 1.190.000	0,711; 0,583
`-t set,get -c 200`	200 clientes	SET 117.000, GET 123.000	1,135; 1,071
`-t set -d 1024`	Valores de 1.024 bytes	SET 114.000	0,367
`-t set -r 100000`	Claves aleatorias entre 100.000	SET 116.000	0,359
`script load "..."`	Un comando propio	106.000	0,415

¿Cómo se ejecuta redis-benchmark?

Apunta la herramienta a un servidor en marcha con -h y -p; sin opciones, ejecuta su batería de pruebas por defecto contra 127.0.0.1:6379. Añade -t para elegir pruebas y -q para ver una línea por prueba.

redis-benchmark -h 10.0.0.12 -p 6379 -c 50 -n 100000 \
  -t set,get -q

La página oficial de benchmark de Redis y la salida de --help de la versión 7.2.6 recogen, entre otras, estas opciones (comprobado el 31 de octubre de 2026):

-c conexiones en paralelo (50 por defecto) y -n peticiones en total (100.000 por defecto).
-d tamaño de los valores de SET y GET en bytes (3 por defecto).
-P comandos por pipeline (1 por defecto, sin pipelining).
-t una lista de pruebas separadas por comas; -q salida resumida; --csv salida en CSV.
-r claves aleatorias dentro de un espacio de claves de ese tamaño. Sin esta opción, todos los comandos usan la misma clave.
-k 1 mantiene las conexiones abiertas (por defecto) y -k 0 vuelve a conectar.
--threads activa el modo multihilo y --cluster el modo clúster, en el que -c debe ser al menos igual al número de nodos.

¿Cómo se lee la salida de redis-benchmark?

Con -q obtienes una línea por prueba: peticiones por segundo y latencia mediana. Sin -q, cada prueba imprime su configuración, una distribución de la latencia por percentiles y un resumen con la media, el mínimo, p50, p95, p99 y el máximo.

La cabecera también muestra los ajustes save y appendonly del servidor, que te dicen si la persistencia formaba parte de la prueba. Nuestra ejecución completa de GET dio 119.617 peticiones por segundo, una media de 0,352 ms, un p95 de 0,559 ms, un p99 de 0,623 ms y un máximo de 0,759 ms. Una petición que llama muchas veces a Redis tiene más probabilidades de dar con una llamada lenta, así que mira también el p99; nuestro artículo sobre la latencia de cola explica por qué.

--csv imprime el resumen como una fila por prueba. Repite las ejecuciones antes de fiarte de una diferencia pequeña: dos ejecuciones de la misma prueba SET nos dieron unas 113.000 y 125.000 peticiones por segundo.

¿Por qué el pipelining cambia tanto las cifras?

Sin -P, cada cliente espera una respuesta antes de enviar su siguiente comando, así que cada comando cuesta un viaje de ida y vuelta completo. Con -P 16, cada cliente envía 16 de golpe, y en nuestra ejecución SET pasó de unas 113.000 a 1.010.000 peticiones por segundo y GET de 118.000 a 1.190.000.

La página oficial considera realista el pipelining, porque muchas aplicaciones Redis lo usan, y aconseja un tamaño de pipeline cercano a la media que tu aplicación puede usar de verdad. Nuestra latencia mediana subió a la vez, a 0,711 y 0,583 ms.

¿Qué pasa si añades más clientes?

Cuando el cuello de botella ya está saturado, más clientes solo añaden espera. En un solo portátil puede ser el servidor o el cliente de benchmark, que usa un único hilo.

Al pasar de 50 a 200 clientes, el rendimiento se mantuvo casi plano (unas 117.000 peticiones SET y 123.000 GET por segundo) mientras la latencia mediana casi se triplicó, hasta 1,135 y 1,071 ms. Es la ley de Little en acción. Cada cliente tiene como mucho un comando en curso, así que -c fija cuántos hay en el sistema, y si el rendimiento no puede crecer, tiene que crecer el tiempo que cada uno pasa ahí. En nuestra ejecución completa de GET, 50 clientes ÷ 119.617 peticiones por segundo dan 0,42 ms por vuelta de cliente, algo por encima de la media medida de 0,352 ms. Con 200 clientes, la misma cuenta da 1,63 ms.

Por eso la herramienta también sigue un modelo de carga cerrado: cuando Redis se atasca, los clientes esperan, y los comandos que tu aplicación habría enviado mientras tanto nunca aparecen. Ni la página oficial ni --help ofrecen una opción de ritmo de peticiones fijo, así que lee sus percentiles teniendo presente la coordinated omission.

¿Cómo mides tu propio comando o un script Lua?

Escribe el comando después de las opciones. La herramienta ejecuta entonces solo ese comando e ignora -t.

redis-benchmark -n 100000 -q \
  script load "redis.call('set','foo','bar')"
redis-benchmark -r 10000 -n 10000 \
  eval 'return redis.call("ping")' 0

La primera línea es el ejemplo de la página oficial; en nuestro portátil corrió a unas 106.000 peticiones por segundo. SCRIPT LOAD solo carga el script, así que usa eval, como en la segunda línea, sacada de --help, para medir su ejecución. Con -r, la ayuda indica que __rand_int__ dentro de un argumento se sustituye por un número aleatorio de 12 cifras en ese rango, y en modo clúster la clave debe contener un {tag} para llegar al nodo correcto.

¿Por qué tu aplicación ve otras cifras?

Tu aplicación mide todo su camino hasta Redis: red, biblioteca cliente, serialización y su propia mezcla de comandos. La página oficial enumera trampas que conviene revisar antes de comparar.

Un bucle de comandos síncronos mide sobre todo la red y la biblioteca cliente.
Con cliente y servidor en la misma máquina, la CPU limita el benchmark. Los sockets de dominio Unix pueden dar alrededor de un 50 % más de rendimiento que el loopback TCP, por ejemplo en Linux.
Cadenas de 4 KB a 100.000 peticiones por segundo necesitan unos 3,2 Gbit/s, más de lo que soporta un enlace de 1 Gbit/s.
Para comparar Redis con una base de datos transaccional, activa AOF y elige una política de fsync adecuada.
Los portátiles varían la frecuencia de la CPU, lo que perjudica la repetibilidad.
INFO a intervalos regulares probablemente no molesta durante una ejecución, mientras que MONITOR ralentiza Redis de forma notable.

¿Muestran estas cifras de portátil la capacidad real de Redis?

No. Muestran un portátil hablando consigo mismo, sin red, con valores de 3 bytes en casi todas las ejecuciones, sin persistencia y con una ejecución por fila.

La tabla enseña cómo mueve cada opción las cifras. La capacidad depende de tu servidor, tu red, el tamaño de tus valores y tu configuración de persistencia.

¿Cuándo no es redis-benchmark la herramienta adecuada?

Cuando quieres saber qué notan los usuarios. Envía comandos sintéticos solo a Redis, mientras que el tiempo de respuesta de una página incluye también el código de la aplicación y sus otras llamadas.

Para eso, pon carga sobre la aplicación o la API que usa Redis y vigila Redis durante la prueba. LoadFocus, que publica este sitio, trabaja en esa capa: ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra tu aplicación web o tu API. No ejecuta redis-benchmark.

Si necesitas más control sobre el tráfico de Redis, el repositorio de memtier_benchmark menciona clientes multihilo, una proporción de lecturas y escrituras, patrones de claves aleatorios o secuenciales, Redis Cluster y TLS (comprobado el 31 de octubre de 2026).

FAQ

¿Está redis-benchmark diseñado para que Redis parezca rápido? No. La página oficial de Redis lo llama un error de concepto habitual: por defecto, la herramienta mantiene como mucho una consulta pendiente por conexión, sin pipelining, y un cliente que usa pipelining puede generar más rendimiento.

¿Cómo se llena una base de datos Redis con redis-benchmark? Ejecuta solo la prueba SET con claves aleatorias, como muestra la ayuda de la herramienta: -t set -n 1000000 -r 100000000 llena alrededor de un millón de claves. Las claves aleatorias pueden repetirse, así que el total final queda algo por debajo.

¿Puede LoadFocus ejecutar redis-benchmark? No. LoadFocus no ejecuta redis-benchmark. Sus planes de prueba JMeter y sus scripts de k6 se dirigen a la aplicación web o la API que está delante de Redis.

Lecturas relacionadas

Cómo usar sysbench: benchmarks de CPU, disco y MySQL

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

sysbench es una herramienta de benchmark open source y multihilo, construida sobre LuaJIT, que incluye pruebas de CPU, memoria, E/S de archivos, hilos y mutex, además de scripts OLTP para MySQL y PostgreSQL. Las pruebas que necesitan datos siguen el mismo ciclo: prepare crea los archivos o tablas de prueba, run ejecuta el benchmark durante un tiempo o un número de eventos fijo, y cleanup borra los datos; las pruebas de CPU y memoria solo necesitan run. Mide una sola máquina o un solo servidor de base de datos, así que no puede decirte cómo se comporta tu aplicación con tráfico real de usuarios.

No hemos ejecutado sysbench para esta guía. Los datos salen de su README y de su código fuente en la rama master de GitHub, comprobados el 31 de octubre de 2026, y los consejos son nuestros.

Tema	sysbench
Licencia	GPLv2
Escrito en	C, con LuaJIT para los scripts
Última versión	1.0.20 (24 de abril de 2020)
Último commit	9 de marzo de 2025
Pruebas integradas	`cpu`, `memory`, `fileio`, `threads`, `mutex`
Scripts de base de datos	Ocho scripts `oltp_`, `bulk_insert`, dos `select_random_`
Drivers de base de datos	MySQL (por defecto), PostgreSQL
Plataformas	Linux, macOS; Windows mediante WSL

¿sysbench sigue teniendo mantenimiento?

Muy poco. La última versión, la 1.0.20, salió en abril de 2020; desde entonces la rama master ha recibido commits ocasionales, ninguno publicado en una versión, el último en marzo de 2025.

La versión 1.0.20 tiene fecha del 24 de abril de 2020. El historial de commits muestra cambios como una distribución uniforme por defecto para --rand-type (2020), un LuaJIT de upstream (2023) y soporte para las bibliotecas cliente de MariaDB (2023), y después cuatro commits de compilación el 9 de marzo de 2025 (comprobado el 31 de octubre de 2026). Los repositorios de paquetes del README se actualizan con cada versión, así que esos cambios requieren compilar desde el código fuente.

¿Cómo funciona una ejecución de sysbench?

Indicas una prueba y un comando: sysbench [options] [testname] [command]. La prueba es una integrada, un script Lua incluido o tu propio script, y el comando suele ser prepare, run, cleanup o help.

Según el README, prepare crea los archivos para fileio o llena la base de datos para los scripts OLTP, cleanup borra esos datos y sysbench <testname> help muestra las opciones de una prueba. Una prueba de disco:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

El código de fileio enumera los modos seqwr, seqrewr, seqrd, rndrd, rndwr y rndrw, con 2 GB de archivos por defecto. Los archivos que caben en memoria pueden servirse desde la caché de páginas, así que usa un tamaño mayor que la RAM si lo que quieres medir es el disco.

¿Cómo medir la CPU y la memoria con sysbench?

Con sysbench cpu run y sysbench memory run. La prueba de CPU informa de eventos por segundo, donde un evento comprueba si cada número hasta un límite es primo, y la de memoria informa de operaciones y MiB transferidos por segundo.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

La prueba de CPU fija --cpu-max-prime en 10000 por defecto, y la prueba de memoria admite un tamaño de bloque, un tamaño total, operaciones de lectura o escritura y acceso secuencial o aleatorio (comprobado el 31 de octubre de 2026). Compara solo ejecuciones con la misma configuración.

¿Cómo se prueba MySQL o PostgreSQL con sysbench?

Elige uno de los scripts OLTP incluidos, llena las tablas con prepare, lanza transacciones desde varios hilos con run y luego borra las tablas con cleanup. MySQL es el driver por defecto; PostgreSQL necesita --db-driver=pgsql y una compilación con soporte para PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

El script OLTP común crea una tabla de 10.000 filas si no pasas --tables y --table-size. En oltp_read_write, cada transacción ejecuta 10 consultas por clave, cuatro consultas por rango, dos actualizaciones y un borrado seguido de una inserción, entre BEGIN y COMMIT (comprobado el 31 de octubre de 2026). Usa más datos que el buffer pool del servidor si quieres lecturas de disco en el resultado.

¿Qué opciones de sysbench importan más?

--threads y --time fijan el tamaño y la duración de una ejecución, --rate fija una tasa objetivo de eventos, y --report-interval, --percentile y --histogram deciden lo que ves.

--threads: hilos de trabajo, 1 por defecto.
--time: segundos, 10 por defecto, 0 para no poner límite. --events limita el número de eventos, y los dos límites se aplican, así que combínalo con --time=0.
--warmup-time: ejecuta primero sin estadísticas, para que las cachés frías no distorsionen el resultado. Solo en master: la versión 1.0.20 no la tiene.
--rate: eventos medios por segundo entre todos los hilos; 0, el valor por defecto, significa lo más rápido posible.
--report-interval: cifras por intervalo cada N segundos, para ver los parones.
--percentile: el percentil de latencia que se muestra, 95 por defecto.
--histogram: un histograma de latencias al final, definido en sb_logger.c.

¿sysbench usa un modelo de carga cerrado o abierto?

Cerrado por defecto: un número fijo de hilos lanza cada uno el siguiente evento en cuanto termina el anterior, así que un servidor lento recibe menos eventos. Con --rate, los eventos llegan según su propio calendario, lo que se acerca más a un modelo de carga abierto.

Nuestro artículo sobre el modelo de carga abierto vs cerrado explica por qué eso cambia lo que mide un benchmark. En el modo por defecto, un parón también retrasa los eventos que habrían empezado durante ese tiempo, y esos retrasos nunca aparecen en las latencias: es la coordinated omission. El archivo fuente principal muestra que --rate encola eventos a intervalos con distribución exponencial, suma a la latencia de cada evento su espera en la cola y se detiene con el error "event queue is full" cuando los hilos no dan abasto (comprobado el 31 de octubre de 2026).

¿Cómo se lee la salida de sysbench?

Empieza por el rendimiento: eventos por segundo, o transacciones y consultas por segundo en los scripts OLTP. Después lee el bloque de latencia en milisegundos: mínimo, media, máximo, el percentil elegido (p95 por defecto) y la suma.

La versión 1.0.20 muestra, en lugar de «Throughput», un bloque «General statistics» con el tiempo total y el número total de eventos. Los nombres de campo vienen del código del informe de base de datos y del archivo fuente principal en master, aquí sin valores:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Un percentil 95 deja fuera el evento más lento de cada veinte. Usa --percentile=99 o añade --histogram cuando importa la cola de la distribución; nuestra guía sobre la latencia de cola explica por qué.

¿Cuándo no es sysbench la herramienta adecuada?

Cuando tu pregunta trata sobre tu aplicación. Una puntuación de CPU muestra lo rápido que una máquina comprueba números primos, y una ejecución OLTP mide el servidor de base de datos con las tablas y consultas de sysbench, sin tu esquema, tu pool de conexiones ni la ruta de red.

Elige pgbench para pruebas nativas de PostgreSQL: la documentación de PostgreSQL describe un escenario por defecto basado a grandes rasgos en TPC-B, además de archivos de script propios (comprobado el 31 de octubre de 2026).
Elige HammerDB para pruebas al estilo TPC-C: su documentación cubre la carga TPROC-C, derivada de TPC-C, para SQL Server, Db2, Oracle, PostgreSQL, MariaDB y MySQL (comprobado el 31 de octubre de 2026).
Elige JMeter con su sampler JDBC Request para combinar SQL y HTTP en un mismo plan de prueba; la guía de planes de prueba de base de datos indica que el .jar del driver va en la carpeta lib de JMeter.

LoadFocus, que publica este sitio, no ejecuta sysbench ni puede conectarse por sí mismo a MySQL o PostgreSQL. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra la capa web o de API que hay delante de la base de datos. Una combinación útil: una ejecución de sysbench para dimensionar el servidor de base de datos y después una prueba de carga de la aplicación para ver si las peticiones reales llegan a ese límite.

FAQ

¿sysbench sigue teniendo mantenimiento? Muy poco. La última versión es la 1.0.20, del 24 de abril de 2020. La rama master ha recibido desde entonces commits ocasionales, ninguno en una versión, el más reciente el 9 de marzo de 2025.

¿Qué significa el percentil 95 en la salida de sysbench? Es la latencia, en milisegundos, dentro de la cual terminó el 95 % de los eventos. 95 es el valor por defecto de la opción --percentile, y puedes fijar otro, como 99.

¿Puede sysbench hacer benchmarks de PostgreSQL? Sí. Los scripts OLTP incluidos funcionan contra PostgreSQL con --db-driver=pgsql cuando sysbench se ha compilado con soporte para PostgreSQL.

¿Puede LoadFocus ejecutar sysbench? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6 contra sitios web y API desde 25 regiones en la nube, y no se conecta directamente a MySQL ni a PostgreSQL.

Lecturas relacionadas

YCSB: cargas de trabajo A-F, ejecución y límites

Sat, 31 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

YCSB, el Yahoo! Cloud Serving Benchmark, es una herramienta open source escrita en Java que carga registros sintéticos en una base de datos y después ejecuta sobre ellos una mezcla fija de lecturas, actualizaciones, inserciones y escaneos mientras registra el rendimiento y la latencia de cada operación. Sus seis cargas de trabajo básicas (core workloads), de la A a la F, son mezclas estándar, así que la misma prueba puede correr contra Cassandra, MongoDB, Redis, HBase y decenas de bases más gracias a los bindings. Mide solo la base de datos, por lo que no dice nada de las consultas reales de tu aplicación ni de la latencia que ven tus usuarios.

No hemos ejecutado YCSB para este artículo. Los datos salen de su repositorio de GitHub, su wiki y su código fuente, comprobados el 31 de octubre de 2026, y las valoraciones son nuestras.

Carga de trabajo	Mezcla de operaciones	Distribución de claves	Ejemplo que da la wiki
A: muchas actualizaciones	50 % lecturas, 50 % actualizaciones	zipfian	Almacén de sesiones que guarda las acciones recientes
B: sobre todo lecturas	95 % lecturas, 5 % actualizaciones	zipfian	Etiquetado de fotos
C: solo lectura	100 % lecturas	zipfian	Caché de perfiles de usuario
D: leer lo más reciente	95 % lecturas, 5 % inserciones	latest	Actualizaciones de estado de usuarios
E: rangos cortos	95 % escaneos, 5 % inserciones	zipfian (escaneos de hasta 100 registros)	Hilos de conversación
F: leer-modificar-escribir	50 % lecturas, 50 % leer-modificar-escribir	zipfian	Base de datos de usuarios

Las mezclas vienen de los archivos del directorio workloads y los ejemplos de la página Core Workloads (comprobado el 31 de octubre de 2026). Cada archivo trae solo 1.000 registros y 1.000 operaciones: suficiente para depurar una instalación y demasiado pocos para un benchmark.

¿Qué es YCSB y sigue teniendo mantenimiento?

Es un generador de carga con un conjunto de cargas de trabajo estándar para comparar bases clave-valor y de tipo "cloud serving", que Yahoo! publicó como open source en 2010 con licencia Apache 2.0. La última versión es de octubre de 2019, y el código todavía recibe pequeños commits.

La página de publicaciones cita el artículo original, "Benchmarking Cloud Serving Systems with YCSB", de Cooper, Silberstein, Tam, Ramakrishnan y Sears (ACM SoCC 2010). La versión 0.17.0 tiene fecha del 6 de octubre de 2019 y no existe ningún tag posterior, mientras que el historial de commits muestra trabajo de 2026, como una opción para seguir adelante cuando falla una inserción y un cambio en el binding de Cloud Spanner del 20 de octubre (comprobado el 31 de octubre de 2026). Esos cambios solo llegan si compilas desde el código fuente, y para eso necesitas Maven 3.

¿Cómo se ejecuta un benchmark con YCSB?

En dos fases que comparten las mismas propiedades: load inserta recordcount registros y después run ejecuta operationcount operaciones con la mezcla de la carga de trabajo. Indicas el binding de tu base de datos y pasas el archivo de la carga de trabajo con -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

La página Running a Workload recoge los detalles en los que más gente tropieza (comprobado el 31 de octubre de 2026). El cliente nunca crea tablas, así que antes tienes que asociar usertable a lo que necesite tu almacén de datos, por ejemplo una tabla en MySQL o un keyspace en Cassandra. Los archivos -P posteriores sobrescriben a los anteriores, y -p los sobrescribe a todos. La fase run necesita el mismo recordcount que la carga, porque elige las claves entre todo el conjunto de datos. -s muestra una línea de estado cada 10 segundos. Como D y E insertan registros, la página Core Workloads aconseja cargar una vez con el archivo de A, ejecutar A, B, C, F y D, y después borrar los datos y volver a cargar para E.

¿Qué controlan -threads y -target?

-threads fija cuántos hilos cliente envían operaciones (uno por defecto) y -target limita el total de operaciones por segundo. Sin objetivo, cada hilo envía la siguiente operación en cuanto vuelve la anterior, así que una base de datos más lenta simplemente recibe menos carga.

Es un modelo de carga cerrado, y nuestro artículo sobre el modelo de carga abierto vs cerrado explica lo que oculta ese modelo. El ejemplo de la wiki, 10 hilos con un objetivo de 100 operaciones por segundo, solo se cumple mientras la latencia media se mantenga por debajo de 100 ms; con pocos hilos, el ritmo alcanzado se queda por debajo del objetivo. Es la ley de Little: los hilos divididos entre la latencia media ponen techo al rendimiento. Si lanzas varios objetivos y anotas la latencia de cada uno, obtienes la curva de nuestra guía sobre rendimiento vs latencia.

¿Cómo se lee la salida de YCSB?

Al final de cada fase, el cliente imprime un bloque [OVERALL] con el tiempo de ejecución y el rendimiento, y luego un bloque por tipo de operación con el recuento, las latencias media, mínima, máxima y por percentil, y un recuento por código de retorno.

Estos nombres de campo salen del código fuente de la 0.17.0; los valores son marcadores de posición:

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

La salida de ejemplo de la wiki muestra milisegundos, pero la medición HdrHistogram por defecto, tanto en la 0.17.0 como en el código actual, da microsegundos, (us). La página Core Properties y la versión 0.17.0 fijan los percentiles por defecto en 95 y 99, que puedes cambiar con hdrhistogram.percentiles; desde abril de 2025 la rama master añade el 50, así que una compilación desde el código fuente también muestra 50thPercentileLatency(us) (comprobado el 31 de octubre de 2026). El README dirige la atención al P99 y más allá, advierte que los percentiles no se pueden promediar y recomienda, si usas varios clientes, guardar archivos de histograma HDR con hdrhistogram.fileoutput=true y combinarlos.

¿Tiene en cuenta YCSB la coordinated omission?

Solo si lo pides, y solo con -target. Por defecto, cada latencia se mide desde el momento en que la operación se envía de verdad, así que un atasco que retrasa las operaciones que vienen detrás apenas se nota.

El código fuente de las mediciones incluye una propiedad measurement.interval que acepta op (por defecto), intended o both (comprobado el 31 de octubre de 2026). Con un objetivo, cada hilo anota el inicio previsto de cada operación; intended mide la latencia desde ese punto y both añade bloques Intended- como [Intended-READ] junto a los habituales. La wiki no menciona la propiedad, así que revisa el código de la versión que compiles. Nuestra guía sobre la coordinated omission explica por qué el inicio previsto da la cifra honesta.

¿Qué bases de datos puede probar YCSB?

Cualquiera que tenga un binding. El archivo de build de la rama master lista 46 módulos de binding, entre ellos Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB y un binding JDBC genérico.

La lista está en el pom.xml, y cada directorio de binding tiene su propio README con las propiedades de conexión, como mongodb.url en el binding de MongoDB (comprobado el 31 de octubre de 2026). Según la página Running a Workload, una sola máquina cliente basta para clústeres de unas 10 máquinas; por encima, arrancas varios clientes, y la página Running a Workload in Parallel reparte la carga entre ellos con insertstart e insertcount.

¿Cuándo no es YCSB la herramienta adecuada?

Cuando tu pregunta es sobre tu aplicación. La carga de trabajo básica escribe registros sintéticos, 10 campos con una longitud de 100 cada uno por defecto, mediante operaciones simples por clave, así que no puede mostrar cómo se comportan bajo carga tus propias consultas, tus índices o el código de tu API.

Para OLTP relacional, pgbench ejecuta contra PostgreSQL un script inspirado en TPC-B y acepta tus propios scripts, y sysbench incluye benchmarks en Lua de tipo OLTP (ambos comprobados el 31 de octubre de 2026).
Para la latencia que ven los usuarios, pon bajo carga la capa HTTP o de API que hay delante de la base de datos. LoadFocus, que publica este sitio, ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra endpoints web y de API. LoadFocus no ejecuta YCSB.

FAQ

¿Cuáles son las cargas de trabajo básicas de YCSB? Seis mezclas estándar: A tiene un 50 % de lecturas y un 50 % de actualizaciones, B un 95 % de lecturas, C solo lecturas, D favorece los registros insertados más recientemente, E hace escaneos cortos y F hace operaciones de lectura-modificación-escritura.

¿Qué diferencia hay entre ycsb load y ycsb run? La fase load inserta el número de registros que fija recordcount. La fase run ejecuta después operationcount operaciones con la mezcla de la carga de trabajo sobre esos registros e informa del rendimiento y la latencia.

¿YCSB sigue teniendo mantenimiento? La última versión, la 0.17.0, salió el 6 de octubre de 2019. El repositorio todavía recibe commits de vez en cuando, el más reciente el 20 de octubre de 2026, así que las correcciones nuevas exigen compilar desde el código fuente.

¿Puede LoadFocus ejecutar benchmarks de YCSB? No. LoadFocus no ejecuta YCSB. Sus planes de prueba JMeter y sus scripts de k6 se dirigen a endpoints web y de API, es decir, a la capa que hay delante del almacén de datos.

Lecturas relacionadas

Pruebas de carga con NBomber: análisis del framework .NET

Wed, 21 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

NBomber es un framework de pruebas de carga para .NET: escribes cada prueba como un escenario en C# o F#, la añades a un proyecto normal y la ejecutas como cualquier otro programa. Las pruebas de carga con NBomber encajan con equipos que ya desarrollan en .NET y quieren sus pruebas de carga en el mismo lenguaje, el mismo repositorio y el mismo ejecutor de pruebas. Solo es gratis para uso personal y académico; una empresa necesita una licencia de pago, y ese dato decide más evaluaciones que cualquier función.

No hemos ejecutado NBomber para este análisis. Los datos salen de la documentación, la página de precios, el repositorio de GitHub y el paquete de NuGet de NBomber, comprobados el 21 de octubre de 2026, y las valoraciones son nuestras.

Tema	NBomber
Licencia	Gratis para uso personal y académico; de pago para organizaciones
Precio para una empresa	Business 1.500 $ al año, Enterprise 2.500 $ al año
Versión actual	6.7.1 (16 de octubre de 2026)
Entorno	.NET Standard 2.1, es decir, .NET Core 3.0 o posterior
Pruebas escritas como	Escenarios en C# o F#
Modelo de carga	Inject (tasa de llegada) o copias constantes
Comprobaciones de aprobación	Umbrales durante la ejecución, aserciones sobre las estadísticas finales
Escalado	NBomber Cluster, licencia Enterprise

¿Quién desarrolla NBomber y es gratis?

Lo desarrolla NBomber LLC, con el código en GitHub. Es gratis para uso personal, de aficionado y académico, y la página de licencia dice sin rodeos que NBomber no es gratis para organizaciones.

La página de licencia incluye en el uso personal los benchmarks, los tutoriales y el contenido de análisis. Dentro de una empresa necesitas una licencia Business o Enterprise, que se emite por organización y no por puesto de desarrollador, sin límite de instancias ni de ejecuciones en paralelo. La página de precios indica 1.500 $ al año para Business y 2.500 $ al año para Enterprise, ambas con 30 días de garantía de devolución. La clave de licencia se pasa al ejecutor con .WithLicense(...) o con un argumento --license, y NBomber necesita acceso a internet para validarla, con validación sin conexión disponible si la pides por correo (comprobado el 21 de octubre de 2026).

La última versión es la v6.7.1, publicada el 16 de octubre de 2026, cuatro días después de la 6.7.0 (comprobado el 21 de octubre de 2026).

¿Cómo funciona un escenario de NBomber?

Un escenario es un nombre más una función asíncrona que NBomber cronometra en cada llamada. Le añades simulaciones de carga y umbrales, lo registras en NBomberRunner y ejecutas el programa.

Esta prueba se salta el warm-up, sube la tasa de llegada a 50 copias nuevas del escenario por segundo en dos minutos, la mantiene diez minutos y termina con código de salida 1 si el 1 % o más de las peticiones han fallado. Usa el plugin NBomber.Http para la petición:

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

La página del cliente HTTP recomienda Http.CreateDefaultClient() en lugar de un simple new HttpClient() y dice que el plugin registra los códigos de estado y los datos transferidos (comprobado el 21 de octubre de 2026). Un umbral por sí mismo únicamente deja constancia del fallo en el informe; la última línea es la que lo convierte en un código de salida que un pipeline puede leer. Sin .WithoutWarmUp(), NBomber ejecuta primero un warm-up de 30 segundos con las simulaciones del escenario, según la página de escenarios (comprobado el 21 de octubre de 2026). Como el escenario es C# normal, todo lo que pueda llamar una biblioteca de .NET se puede someter a carga de la misma forma.

¿Qué modelos de carga ofrece NBomber?

Los dos. Las simulaciones inject lanzan copias nuevas a un ritmo fijo, hagan lo que hagan las anteriores, que es un modelo de carga abierto; las simulaciones constant mantienen un número fijo de copias en marcha, que es uno cerrado.

La página de simulaciones de carga las enumera (comprobado el 21 de octubre de 2026):

Abiertas: Inject, RampingInject, InjectRandom e IterationsForInject.
Cerradas: KeepConstant, RampingConstant e IterationsForConstant.
Control de tiempo: Pause, que retrasa el inicio de un escenario o lo pausa durante un tiempo fijado.

Nuestro artículo sobre el modelo de carga abierto vs cerrado explica cuál encaja con tu tráfico. Un sitio web público suele comportarse como el modelo abierto; un grupo fijo de clientes internos, como el cerrado.

¿Cómo funcionan los umbrales y las comprobaciones de aprobación?

Los umbrales en tiempo de ejecución revisan las estadísticas en curso, cada 5 segundos por defecto, y aparecen en el informe HTML. Las aserciones, escritas con xUnit o NUnit, revisan las estadísticas finales tras la ejecución, y una aserción fallida termina la ejecución con estado fallido.

La página de umbrales muestra comprobaciones sobre el porcentaje de errores, los códigos de estado, los percentiles de latencia (p50, p75, p95, p99 y máximo), las peticiones por segundo y los bytes transferidos. Por defecto un umbral no detiene la prueba; abortWhenErrorCount la detiene tras un número dado de comprobaciones fallidas (comprobado el 21 de octubre de 2026). La página no indica un código de salida, por eso el ejemplo de arriba devuelve uno a partir del resultado. Nuestra guía de criterios de aprobación en pruebas de carga ayuda a elegir los límites.

¿Qué protocolos puede probar NBomber?

Cualquier protocolo que hable una biblioteca de .NET, porque NBomber solo cronometra el código que le das. Hay plugins listos para HTTP, WebSockets, MQTT y AMQP, además de una opción WebBrowser.

La página de introducción describe el framework como independiente del protocolo, y la página de precios incluye esos plugins en todos los planes, también en el gratuito. Eso abarca también las bases de datos y las colas de mensajes que llamas con sus propios clientes de .NET (comprobado el 21 de octubre de 2026). A cambio, fuera de los plugins tienes que escribir y mantener tú el código del cliente.

¿Cómo se escala una prueba de NBomber?

Con NBomber Cluster: un Coordinator orquesta la ejecución y los Agents ejecutan los escenarios, todos comunicados a través de un broker de mensajes NATS. Cluster forma parte de la licencia Enterprise.

La introducción al clúster explica los roles, y la página de licencia indica que los desarrolladores pueden probarlo en local con un Local Dev Cluster antes de comprar; la página del Local Dev Cluster lo limita a 1 Coordinator y 2 Agents y detiene cada ejecución al cabo de un minuto (comprobado el 21 de octubre de 2026). La integración con Kubernetes de NBomber Studio, también exclusiva de Enterprise, prepara por ti NATS y los pods de los Agents. Sin Cluster, un proceso de NBomber corre en una sola máquina; la página de requisitos del sistema recomienda de 4 a 8 núcleos de CPU para carga alta.

LoadFocus, que publica este sitio, no ejecuta pruebas de NBomber. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube.

¿Qué hace bien NBomber y dónde están sus límites?

Es fuerte para equipos .NET: las pruebas son código C# o F#, cualquier cliente de .NET se convierte en una prueba de carga y los dos modelos de carga vienen integrados. Sus límites son la licencia para empresas, un ecosistema de un solo lenguaje y las ejecuciones distribuidas de pago.

Las pruebas viven junto al código de la aplicación, con el mismo IDE, los mismos paquetes y las mismas revisiones.
Los umbrales vienen integrados, y las aserciones se ejecutan dentro de las pruebas de xUnit o NUnit que ya tienes.
El uso comercial requiere licencia, incluso para un solo desarrollador.
Las ejecuciones distribuidas requieren Enterprise y un broker NATS.
Quien no conozca .NET tendrá que aprender antes C# o F#.

¿Cuándo elegir k6, Gatling o JMeter en lugar de NBomber?

Elige otra herramienta cuando tu equipo no programe en .NET o cuando el coste de la licencia no encaje.

Elige k6 si quieres scripts en JavaScript y una herramienta open source sin coste de licencia para uso en empresa: su repositorio tiene licencia AGPL-3.0 (comprobado el 21 de octubre de 2026). LoadFocus ejecuta scripts de k6 desde 25 regiones en la nube, aunque lanza los escenarios arrival-rate con un número fijo de usuarios. Elige Gatling para una herramienta de código sobre la JVM; nuestro análisis de Gatling la cubre. Elige JMeter si tus testers prefieren una interfaz gráfica o necesitas samplers JDBC, JMS o LDAP de serie. El repaso de herramientas de pruebas de carga open source las compara.

FAQ

¿NBomber es gratis para uso comercial? No. NBomber solo es gratis para uso personal y académico. Una empresa necesita una licencia Business de 1.500 $ al año o una licencia Enterprise de 2.500 $ al año.

¿Qué versiones de .NET admite NBomber? Apunta a .NET Standard 2.1, así que funciona en .NET Core 3.0 y en todas las versiones de .NET posteriores. La documentación recomienda .NET 10.

¿Puede LoadFocus ejecutar pruebas de NBomber? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6. Para ejecutar NBomber en más de una máquina, usa NBomber Cluster, que requiere una licencia Enterprise.

Lecturas relacionadas

Pruebas de carga con Tsung: la herramienta Erlang a fondo

Wed, 21 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Tsung es una herramienta de pruebas de carga open source escrita en Erlang que describe cada prueba en un archivo XML y puede repartir la carga entre muchas máquinas cliente. Las pruebas de carga con Tsung siguen teniendo sentido para protocolos que cubren pocas herramientas, como XMPP, LDAP o PostgreSQL a nivel de protocolo, y para muchísimos usuarios con hardware modesto. La última versión de Tsung salió en marzo de 2023, así que para pruebas nuevas de HTTP o de API a la mayoría de los equipos les irá mejor con k6, Gatling o JMeter.

No hemos ejecutado Tsung para este análisis. Los datos salen de la documentación y del repositorio de GitHub de Tsung, comprobados el 21 de octubre de 2026, y las valoraciones son nuestras.

Tema	Tsung
Licencia	GPL-2.0
Escrito en	Erlang (requiere Erlang/OTP R16B03 o posterior)
Última versión	1.8.0 (2 de marzo de 2023)
Pruebas escritas como	Archivos de configuración XML
Modelo de carga	Usuarios nuevos por fase de llegada (abierto)
Protocolos	HTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, TCP/UDP en bruto (algunos experimentales)
Escalado	Máquinas cliente por SSH sin contraseña
Informes	Panel en vivo en el puerto 8091, informe HTML con `tsung_stats.pl`

¿Quién mantiene Tsung y sigue activo el proyecto?

ProcessOne aloja el proyecto en GitHub con licencia GPL-2.0. Se mantiene, pero con poco movimiento: la última versión, la 1.8.0, es de marzo de 2023, y desde entonces solo llegan de vez en cuando pull requests fusionadas.

El repositorio muestra su último commit el 2 de marzo de 2026, una pull request que sustituye llamadas obsoletas, y el tag v1.8.0 tiene fecha del 2 de marzo de 2023 (comprobado el 21 de octubre de 2026). La documentación todavía lleva el título 1.7.0, así que revisa el repositorio cuando un detalle parezca desfasado. Un proyecto tranquilo también significa menos respuestas cuando algo sale mal.

¿Cómo funciona una prueba de Tsung?

Una prueba es un archivo XML con cuatro partes principales: las máquinas cliente, los servidores de destino, las fases de carga y las sesiones de usuario. Cada usuario nuevo elige una sesión según su probabilidad y ejecuta sus peticiones en orden.

Este fragmento lanza cinco usuarios nuevos por segundo durante diez minutos; cada uno carga una lista de productos, hace una pausa de unos dos segundos y envía una petición POST al carrito:

<load>
  <arrivalphase phase="1" duration="10" unit="minute">
    <users arrivalrate="5" unit="second"/>
  </arrivalphase>
</load>
<sessions>
  <session name="browse" probability="100"
           type="ts_http">
    <request><http url="/products" method="GET"/></request>
    <thinktime value="2" random="true"/>
    <request><http url="/cart" method="POST"
                   contents="sku=A-100"/></request>
  </session>
</sessions>

La página de sesiones dice que las probabilidades de las sesiones deben sumar 100 (desde la 1.5.0 también valen pesos) y que un tiempo de reflexión aleatorio sigue una distribución exponencial alrededor de su valor, salvo que indiques un rango con min y max (comprobado el 21 de octubre de 2026). Para HTTP y PostgreSQL hay un grabador proxy que convierte una sesión de navegador o de cliente en este XML.

¿Qué modelo de carga usa Tsung?

Un modelo de carga abierto. Cada fase de llegada lanza usuarios nuevos a un intervalo o una tasa fijos, hagan lo que hagan los usuarios que ya están en marcha, y una fase termina cuando se acaba su tiempo aunque sus sesiones no hayan terminado.

La página de carga recoge los controles: interarrival o arrivalrate por fase, maxnumber para limitar los usuarios que lanza una fase, un atributo duration sobre toda la carga para detener la prueba a una hora fija, y wait_all_sessions_end para que la fase siguiente espere a que terminen los usuarios actuales (comprobado el 21 de octubre de 2026). Nuestros artículos sobre el modelo de carga abierto vs cerrado y sobre el tiempo de reflexión explican cómo esas decisiones cambian lo que mide una prueba.

¿Qué protocolos puede probar Tsung?

Más que la mayoría de las herramientas de pruebas de carga: HTTP (incluido SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT y TCP, UDP o SSL en bruto. La documentación marca como experimentales los plugins de MySQL, WebSocket, AMQP y MQTT, con AMQP solo en 0.9.1 y MQTT solo en 3.1.

La página de funciones describe cada plugin (comprobado el 21 de octubre de 2026). En XMPP y PostgreSQL Tsung lleva mucho tiempo con pocos rivales: habla el protocolo por sí mismo, así que pruebas el servidor y no una biblioteca cliente. Para aplicaciones en tiempo real, nuestro repaso de herramientas de pruebas de carga WebSocket pone a Tsung junto a opciones más recientes.

¿Cómo se reparte una prueba de Tsung entre varias máquinas?

Enumeras las máquinas cliente en el XML, y el controlador lanza la carga en ellas por SSH sin contraseña, o por rsh. A cada cliente se le puede dar un peso, un límite de usuarios y un número de CPU.

La página de clientes y servidor explica que Tsung ejecuta una máquina virtual de Erlang por cada CPU que declares con cpu en cada cliente (una por defecto) y arranca una nueva cuando una VM llega a maxusers. También puede tomar las máquinas cliente de un planificador de lotes como PBS, LSF u OAR. La página de instalación pide Erlang/OTP R16B03 o posterior y, de forma opcional, Perl 5 y gnuplot, o Python y matplotlib, para los gráficos (comprobado el 21 de octubre de 2026).

LoadFocus, que publica este sitio, no ejecuta archivos de Tsung. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube.

¿Cómo se leen los resultados de Tsung?

De dos maneras: con un panel en vivo que sirve el controlador en el puerto 8091 y con un informe HTML que genera el script tsung_stats.pl después de la ejecución.

La página de informes dice que el panel existe desde la 1.6.0, muestra el estado actual, construye los gráficos mientras corre la prueba y se detiene cuando la prueba termina, salvo que arranques Tsung con -k (comprobado el 21 de octubre de 2026). El informe cubre tiempos de respuesta y de conexión, transacciones, peticiones por segundo y códigos de error, y puede incluir datos de CPU, memoria y red de los servidores, recogidos con agentes de Erlang, SNMP o munin. La documentación no describe ningún umbral de aprobación, así que un pipeline de CI tiene que analizar los resultados por su cuenta; nuestra guía de criterios de aprobación en pruebas de carga explica qué revisar.

¿Qué hace bien Tsung y dónde están sus límites?

Es fuerte en variedad de protocolos, fases de llegada abiertas y muchos usuarios por máquina, que la documentación cifra en miles por CPU. Sus límites son un historial de versiones con poco movimiento, scripts solo en XML y ninguna comprobación de aprobación integrada.

Pruebas de XMPP, LDAP y bases de datos a nivel de protocolo, sin escribir código cliente.
Reparto por SSH sin más, sin broker ni servicio adicional.
Monitorización de los servidores en el mismo informe.
Cualquier lógica más allá del XML exige Erlang, que pocos equipos escriben.
Erlang tiene que estar instalado en el controlador y en cada cliente.

¿Cuándo elegir k6, Gatling o JMeter en lugar de Tsung?

Elige otra herramienta cuando pruebes HTTP o API y quieras un proyecto activo con scripts en un lenguaje habitual.

Elige k6 para scripts en JavaScript con umbrales dentro del propio script y un proyecto activo (comprobado el 21 de octubre de 2026). Elige Gatling para simulaciones basadas en código sobre la JVM; nuestro análisis de Gatling lo explica a fondo. Elige JMeter si tus testers quieren una interfaz gráfica o necesitas samplers JDBC, JMS o LDAP con un gran ecosistema de plugins. LoadFocus ejecuta JMeter y k6 desde 25 regiones en la nube, y el repaso de herramientas de pruebas de carga open source compara estas herramientas.

FAQ

¿Tsung sigue teniendo mantenimiento? Sí, aunque con poco movimiento. La última versión, la 1.8.0, salió el 2 de marzo de 2023, y el repositorio todavía recibe de vez en cuando cambios fusionados, el último en marzo de 2026.

¿Qué protocolos admite Tsung? HTTP y SOAP, WebDAV, XMPP, PostgreSQL, LDAP y TCP, UDP o SSL en bruto, además de MySQL, WebSocket, AMQP y MQTT, que la documentación marca como experimentales.

¿Puede LoadFocus ejecutar pruebas de Tsung? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6. Para repartir una prueba de Tsung entre varias máquinas, enuméralas como clientes en el archivo XML.

Lecturas relacionadas

Puntuación Apdex: qué es y cómo se calcula

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Una puntuación Apdex es un número entre 0 y 1 que indica qué parte de las peticiones fue lo bastante rápida para quien las esperaba. Eliges un tiempo objetivo T: las respuestas hasta T cuentan entero, las que llegan hasta cuatro veces T cuentan la mitad y las más lentas cuentan cero. Un resultado de 1 significa que todas las peticiones cumplieron el objetivo, y 0 que todas fueron demasiado lentas.

Zona	Tiempo de respuesta	Peso en la puntuación
Satisfecho (satisfied)	hasta T	1
Tolerable (tolerating)	más de T, hasta 4T	0,5
Frustrado (frustrated)	más de 4T	0

Los datos de abajo salen de la documentación y del código fuente de las herramientas, comprobados el 19 de octubre de 2026.

¿Cómo se calcula una puntuación Apdex?

Suma las peticiones satisfechas y la mitad de las tolerables, y divide entre el total. El resultado siempre queda entre 0 y 1.

Apdex(T) = (satisfied + tolerating / 2) / total

La documentación de Apdex de New Relic resuelve un ejemplo con T en 500 ms: de 200 peticiones, 170 terminaron en 500 ms o menos, 20 tardaron entre 500 ms y 2 segundos, y 10 fallaron o tardaron más. Eso da (170 + 20 / 2) / 200 = 0,90 (comprobado el 19 de octubre de 2026).

Un segundo ejemplo muestra por qué la puntuación sirve en una prueba de carga. Supón una ejecución de 10.000 peticiones con T en 300 ms: 8.200 terminan en 300 ms, 1.300 entre 300 ms y 1,2 segundos, y 500 tardan más. El Apdex es (8.200 + 650) / 10.000 = 0,885. La misma ejecución puede mostrar sin problema una media de 280 ms, que por sí sola parece bien y esconde las 500 peticiones de más de un segundo.

¿De dónde viene Apdex?

Apdex, abreviatura de Application Performance Index, es un estándar abierto de un grupo de empresas llamado Apdex Alliance. Peter Sevcik, de NetForecast, fundó la Alliance en 2004.

El artículo de Wikipedia sobre Apdex cita el artículo de Sevcik de 2005 y recoge la regla de 4T. El Apdex Users Group dice ahora que las reglas de los umbrales T y F «se han vuelto flexibles» (comprobado el 19 de octubre de 2026), y las herramientas aprovechan esa libertad.

¿Cómo la calculan JMeter, Artillery y LoadFocus?

Las tres parten de T = 500 ms. Se diferencian en dónde termina la zona tolerable y en qué hacen con las peticiones fallidas, así que una misma ejecución puede dar tres valores algo distintos.

Herramienta	T por defecto	Tolerable hasta	Peticiones fallidas
Panel HTML de JMeter	500 ms	1.500 ms	cuentan como frustradas
Plugin `apdex` de Artillery	500 ms	4T (2.000 ms)	solo se puntúan las respuestas
Página de resultados de LoadFocus	500 ms, fijo	4T (2.000 ms)	se clasifican por tiempo de respuesta
New Relic APM	se fija por aplicación	4T	los errores de servidor son frustrados

JMeter. El informe del panel incluye una tabla APDEX por transacción. Sus valores por defecto son jmeter.reportgenerator.apdex_satisfied_threshold=500 y apdex_tolerated_threshold=1500, así que la zona tolerable acaba en 3T salvo que la cambies, y apdex_per_transaction fija umbrales distintos por sampler. En ApdexSummaryConsumer una muestra fallida suma al total y nunca a las satisfechas o tolerables, de modo que cada fallo baja la puntuación (comprobado el 19 de octubre de 2026).

Artillery. El plugin apdex solo funciona con el motor HTTP y publica los contadores apdex.satisfied, apdex.tolerated y apdex.frustrated. Su código en artillery-plugin-apdex 1.24.0 clasifica cada respuesta por su tiempo total frente a T y 4T, y luego imprime la puntuación con una etiqueta: excellent desde 0,94, good desde 0,85, fair desde 0,70, poor desde 0,49 y unacceptable por debajo. Una petición que nunca recibe respuesta nunca se puntúa (comprobado el 19 de octubre de 2026). Nuestro análisis de Artillery cubre la herramienta en sí.

LoadFocus, que publica este sitio, muestra la puntuación Apdex en la pestaña Insights del resultado de una prueba de carga, junto a un histograma de tiempos de respuesta. T está fijo en 500 ms y la zona tolerable acaba en 2.000 ms; T no se puede cambiar. Cada muestra se clasifica por su tiempo de respuesta, con las partes satisfecha, tolerable y frustrada junto a la puntuación.

¿Cómo se elige el umbral T?

Elige T según lo que esperan los usuarios de esa página o ese endpoint, y fíjalo por transacción si tu herramienta lo permite. Un único T para toda una aplicación mezcla un endpoint de búsqueda rápido y una exportación de informes lenta en un solo número.

Algunas reglas prácticas:

Parte de un objetivo real. Si ya tienes un objetivo de latencia como «el 95 % de las llamadas de pago en menos de 400 ms», T = 400 ms hace que el Apdex y el objetivo cuenten lo mismo.
Mantén el mismo T entre ejecuciones. Un Apdex solo se compara con otro medido con el mismo T. Escríbelo como Apdex(0.4) o «Apdex con T = 400 ms» para que nadie compare umbrales distintos.
Iguala también la zona tolerable. El valor por defecto de JMeter acaba en 3T y los demás en 4T. Antes de comparar un informe de JMeter con otra herramienta, pon apdex_tolerated_threshold en cuatro veces T.
No ajustes T para que una versión apruebe. Mover T después de una mala ejecución cambia la regla de medir, y la tendencia que seguías desaparece.

¿Qué es una buena puntuación Apdex?

El plugin de Artillery llama excellent a 0,94 o más, good a 0,85-0,94 y poor o peor a todo lo que queda bajo 0,70. Esas etiquetas solo significan algo si T se eligió con honestidad.

Un Apdex de 0,95 con T = 2 segundos puede describir un servicio más lento que un 0,80 con T = 200 ms. Cuando fijes un criterio para publicar una versión, escribe el umbral y la puntuación juntos («Apdex(0.5) de al menos 0,9») y compruébalo junto a un límite de percentil, porque cada uno detecta problemas distintos.

¿Qué oculta Apdex?

Comprime toda la distribución de tiempos de respuesta en tres franjas, así que no puede decir cuán lentas fueron las peticiones frustradas. Una petición de 2,1 segundos y otra de 30 segundos bajan la puntuación exactamente lo mismo.

Por eso funciona mejor junto a otros números:

Los percentiles muestran cuán lentas son las peticiones lentas. Nuestra guía sobre la latencia de cola explica por qué el percentil 99 importa en cuanto una página llama a varios servicios.
La tasa de errores detecta fallos que tu herramienta quizá no puntúe. Artillery nunca puntúa peticiones sin respuesta y New Relic cuenta los errores de servidor como frustrados, así que lee el número de errores aparte.
El tamaño de la muestra importa: New Relic advierte que por debajo de unas 100 peticiones por minuto la puntuación es inestable.
El sesgo de medición también cuenta. Un generador de carga que espera las respuestas lentas envía menos peticiones en los periodos lentos, y el Apdex parece mejor que la realidad; consulta la coordinated omission.

¿Cómo se usa Apdex en una prueba de carga?

Úsalo como resumen para quien no va a leer un histograma, y deja la decisión de aprobar o suspender en límites explícitos.

Una rutina que funciona:

Fija T por transacción clave a partir de tu objetivo de latencia.
Ejecuta la prueba y anota el Apdex con ese T, junto con los percentiles 95 y 99 y la tasa de errores.
Compara el Apdex con la ejecución anterior con el mismo T. Una caída de 0,93 a 0,86 es una señal clara incluso para alguien de fuera del equipo.
Haz fallar el build con límites de percentil y de errores, como explica nuestra guía de criterios de aprobación en pruebas de carga, e informa del Apdex al lado.

FAQ

¿Una puntuación Apdex más alta es mejor? Sí. 1,0 significa que todas las peticiones terminaron dentro de T, y 0 que todas superaron el límite tolerable o contaron como frustradas.

¿Cuál es el umbral Apdex por defecto en JMeter? El panel HTML usa 500 ms para satisfecho y 1.500 ms para tolerable. Se cambian con jmeter.reportgenerator.apdex_satisfied_threshold y apdex_tolerated_threshold.

¿Apdex incluye los errores? Depende de la herramienta. JMeter cuenta las muestras fallidas como frustradas y New Relic hace lo mismo con los errores de servidor, mientras que el plugin de Artillery solo puntúa las peticiones que recibieron respuesta.

¿Puedo comparar puntuaciones Apdex de dos herramientas? Solo si coinciden T, el límite tolerable y el tratamiento de los errores. Si no, compara mejor los percentiles y las tasas de errores de base.

Lecturas relacionadas

Pruebas de carga con Artillery: análisis de la herramienta

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Artillery es una herramienta de pruebas de carga open source que corre sobre Node.js y describe cada prueba en un archivo YAML, TypeScript o JavaScript. Las pruebas de carga con Artillery encajan con equipos que viven en el ecosistema JavaScript, que quieren que lleguen usuarios nuevos a un ritmo fijo o que quieren pruebas de navegador con Playwright en la misma herramienta. A los equipos que quieren un único binario sin runtime les va mejor k6, y a los que necesitan muchos protocolos de serie, JMeter.

No hemos ejecutado Artillery para este análisis. Los datos salen de la documentación, el repositorio, el paquete de npm y la página de precios de Artillery, comprobados el 19 de octubre de 2026, y las valoraciones son nuestras.

Tema	Artillery
Licencia	MPL-2.0; algunos módulos de Azure bajo BSL
Runtime	Node.js, última LTS (el paquete pide 22.18.0 o posterior)
Versión actual	2.0.34 (14 de agosto de 2026)
Pruebas escritas en	YAML, TypeScript o JavaScript
Modelo de carga	Usuarios virtuales nuevos por segundo, por fases
Motores integrados	HTTP, WebSocket, Socket.IO, Playwright
Comprobaciones de aprobación	Plugin `ensure`, código de salida distinto de cero
Escalado	`run-lambda`, `run-fargate`, `run-aci`
Informes alojados	Artillery Cloud, opcional, con nivel gratuito

¿Quién desarrolla Artillery y con qué licencia?

Lo mantiene Artillery Software Inc. en GitHub. Casi todo el código está bajo MPL-2.0, que permite el uso comercial; algunos módulos específicos de Azure están bajo la Business Source License.

El README del repositorio permite usar Artillery en Azure para evaluación y pruebas de concepto, y exige una licencia comercial para el uso comercial o en producción allí. La última versión es la 2.0.34, publicada en npm el 14 de agosto de 2026, y sus metadatos piden Node.js 22.18.0 o posterior; la guía de instalación recomienda la versión LTS más reciente (comprobado el 19 de octubre de 2026).

¿Cómo funciona un script de prueba de Artillery?

Un script tiene dos partes: config, que fija el destino, las fases de carga y los plugins, y scenarios, que enumera lo que hace cada usuario virtual. Puedes escribirlo en YAML o exportar config y scenarios desde un archivo TypeScript o JavaScript.

Esta prueba sube de 5 a 50 usuarios nuevos por segundo en dos minutos, mantiene 50 por segundo durante diez minutos y falla si el percentil 99 del tiempo de respuesta llega a 800 ms:

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

Según la referencia de scripts de prueba, los cuatro tipos de fase son una tasa de llegada constante, una rampa lineal con rampTo, un arrivalCount fijo repartido en un periodo y una pause. El código propio cargado con config.processor puede ser un módulo TypeScript en local y en Fargate, pero no en Lambda (comprobado el 19 de octubre de 2026).

¿Qué modelo de carga usa Artillery?

Artillery lanza usuarios virtuales nuevos al ritmo que fijes, hayan terminado o no los anteriores. Es un modelo de carga abierto, que mantiene las llegadas aunque el sistema se vuelva lento.

Cada usuario nuevo elige un escenario, lo ejecuta y se va, así que un sistema lento acumula usuarios como lo haría el tráfico real. maxVusers limita el número de usuarios simultáneos de una fase si necesitas proteger el generador de carga. Nuestro artículo sobre el modelo de carga abierto vs cerrado explica la diferencia, y la ley de Little muestra cómo la tasa de llegada y el tiempo de respuesta fijan el número de usuarios simultáneos.

¿Qué protocolos y navegadores puede probar?

HTTP es el motor por defecto, y WebSocket, Socket.IO y Playwright vienen integrados. gRPC y AWS Kinesis necesitan motores que se instalan aparte.

La página de motores describe el modelo: cada escenario corre en un motor, y puedes escribir el tuyo. En npm, artillery-engine-grpc va por la 0.0.9 y artillery-engine-kinesis por la 1.1.1, ambos bajo MPL-2.0. El motor de Playwright ejecuta tu código de Playwright en navegadores headless reales y publica Web Vitals como TTFB, FCP y LCP por página. La documentación avisa de que un navegador separado por usuario, en lugar de un contexto de navegador, necesita mucha más CPU y memoria (comprobado el 19 de octubre de 2026). Nuestro repaso de herramientas de pruebas de carga WebSocket sitúa a Artillery junto a otras opciones para aplicaciones en tiempo real.

¿Cómo encaja en la CI?

El plugin ensure convierte métricas en comprobaciones de aprobación, y una comprobación fallida hace que Artillery termine con un código distinto de cero. Eso basta para que cualquier sistema de CI haga fallar el build.

La referencia de ensure ofrece dos tipos de comprobación: thresholds, donde una métrica debe quedar por debajo de un valor, y conditions, que combinan métricas en una expresión como http.response_time.p95 < 250 and http.request_rate > 1000. Una condición marcada con strict: false avisa sin hacer fallar. El plugin apdex añade una puntuación Apdex a las pruebas HTTP, con un umbral por defecto de 500 ms (comprobado el 19 de octubre de 2026); nuestro artículo sobre la puntuación Apdex explica cómo leerla. Para un archivo de workflow, consulta nuestra guía de pruebas de carga en GitHub Actions.

¿Cómo se escala una prueba de Artillery?

Desde la línea de comandos, en tu propia cuenta de nube: run-lambda y run-fargate en AWS, run-aci en Azure Container Instances. Artillery crea los recursos que necesita la ejecución y borra después los temporales.

La guía de Fargate enumera los recursos y los permisos de IAM implicados. La guía de Lambda indica sus límites: una prueba no puede durar más de 15 minutos, una prueba en marcha no se puede detener y los hooks before y after se ejecutan una vez por worker. La guía de Azure exige Artillery 2.0.19 o posterior y, fuera de la evaluación, una suscripción (comprobado el 19 de octubre de 2026).

LoadFocus, que publica este sitio, no ejecuta scripts de Artillery. Ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube, así que para Artillery los comandos anteriores son la forma de escalar.

¿Cuánto cuesta Artillery Cloud?

El panel es opcional: los resultados solo llegan allí si ejecutas con --record y una clave de API. Los planes van de un nivel gratuito a 499 $ al mes.

La página de precios indica (comprobado el 19 de octubre de 2026):

Free: 30 informes al mes, 1 mes de conservación, 2 miembros, pruebas distribuidas de hasta 5 workers y 30 minutos.
Team, 199 $ al mes: 1.000 informes, 6 meses, 8 miembros, hasta 25 workers y 2 horas.
Business, 499 $ al mes: 2.500 informes, 18 meses, sin límite de miembros, workers ni duración.

El SSO empresarial, los registros de auditoría y los SLA de soporte empiezan en 1.199 $ al mes, y la facturación anual ahorra un 20 %.

¿Qué hace bien Artillery y dónde están sus límites?

Destaca en carga por tasa de llegada, scripts cortos y legibles y pruebas de navegador con Playwright. Flojea cuando necesitas un único binario, muchos protocolos sin complementos o usar Azure sin licencia.

Como herramienta de Node.js puede usar cualquier módulo de npm en funciones propias, a cambio de un runtime más en cada máquina de pruebas. Límites que la propia documentación reconoce:

Las ejecuciones en Lambda se cortan a los 15 minutos y no se pueden cancelar.
El código propio en TypeScript (config.processor) no corre en Lambda.
gRPC y Kinesis son motores aparte.
El uso en producción en Azure exige una licencia comercial.

¿Cuándo elegir k6, JMeter o Locust en lugar de Artillery?

Elige otra herramienta cuando su runtime, sus protocolos o su lenguaje encajen mejor con tu equipo.

Elige k6 si quieres un binario de Go sin Node.js que mantener y umbrales en el script. Nuestra comparativa k6 vs Artillery pone las dos frente a frente. LoadFocus ejecuta scripts de k6 desde 25 regiones en la nube, aunque ejecuta los escenarios arrival-rate con un número fijo de usuarios; para mantener una tasa de llegada, ejecútalos con el propio k6.

Elige JMeter si necesitas JDBC, JMS, LDAP o FTP de serie, o si tus testers montan las pruebas en una interfaz gráfica.

Elige Locust si tu equipo escribe Python; nuestro análisis de Locust lo cubre. El repaso de herramientas de pruebas de carga open source las pone todas lado a lado.

FAQ

¿Artillery es gratis para uso comercial? La CLI está casi toda bajo MPL-2.0, que permite el uso comercial. La excepción es Azure: el uso comercial o en producción de sus módulos de Azure exige una licencia comercial.

¿Puede Artillery ejecutar pruebas de navegador? Sí. Su motor de Playwright integrado ejecuta tu código de Playwright en navegadores headless y publica Web Vitals de cada página.

¿Puede LoadFocus ejecutar scripts de Artillery? No. LoadFocus ejecuta planes de prueba JMeter y scripts de k6. Para escalar una prueba de Artillery, usa run-lambda, run-fargate o run-aci.

Lecturas relacionadas

Azure Load Testing: análisis del servicio de Microsoft

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Azure Load Testing es el servicio gestionado de Microsoft para ejecutar pruebas de JMeter y Locust a gran escala desde Azure, con cobro por hora de usuario virtual. Encaja bien cuando el sistema que pruebas corre en Azure, porque puede traer métricas de servidor de Azure Monitor y llegar a endpoints privados dentro de una red virtual. A los equipos que escriben scripts de k6, no tienen suscripción de Azure o prueban desde fuera de las regiones de Azure les resultarán más sencillos otros servicios.

No hemos ejecutado Azure Load Testing para este análisis. Los datos salen de la documentación y la página de precios de Microsoft, comprobadas el 19 de octubre de 2026, y las valoraciones son nuestras.

Tema	Azure Load Testing
Tipo	Servicio gestionado en el hub Azure App Testing
Frameworks de prueba	Solo Apache JMeter y Locust
Opción sin código	Prueba rápida por URL, hasta cinco peticiones HTTP
Escala por ejecución	Hasta 400 instancias de motor
Prueba más larga	24 horas
Origen de la carga	La región del recurso, o hasta 5 regiones
Endpoints privados	Sí, mediante inyección en una red virtual
Precio	0,15 $ por hora de usuario virtual, 0,06 $ a partir de 10.000
Conservación	6 meses; métricas de cliente 365 días

¿Qué es Azure Load Testing?

Es un servicio totalmente gestionado que ejecuta tu prueba de carga en los motores de prueba de Microsoft, así que nunca montas ni parcheas generadores de carga. Creas un recurso de pruebas de carga en una región de Azure, le añades pruebas y lanzas ejecuciones desde el portal, la Azure CLI o un pipeline.

La página de introducción dice que la aplicación probada puede estar en cualquier sitio: en Azure, en tus instalaciones o en otra nube. Microsoft incluye ahora el servicio en el hub Azure App Testing, junto a Playwright Workspaces; el inicio rápido de Locust crea el recurso desde ese hub (comprobado el 19 de octubre de 2026).

¿Qué tipos de prueba y herramientas admite?

Tres caminos: una prueba rápida por URL, un script de JMeter subido o un script de Locust subido. La documentación dice claramente que no admite ningún otro framework de pruebas.

La prueba rápida admite hasta cinco peticiones HTTP y un objetivo de usuarios virtuales o de peticiones por segundo. Cada motor maneja hasta 250 usuarios virtuales, así que 400 usuarios corren en dos motores de 200 cada uno.

Con JMeter puedes usar plugins de jmeter-plugins.org o subir los tuyos, y la introducción afirma que funciona cualquier protocolo que admita JMeter, como una conexión a base de datos o una cola de mensajes. Con Locust puedes añadir plugins de Locust y otras bibliotecas de Python. La propia documentación de Locust remite al servicio como su opción alojada, y nuestro análisis de Locust cubre la herramienta en sí. Los scripts de k6, Gatling y Artillery no se ejecutan aquí (comprobado el 19 de octubre de 2026).

¿Cómo funcionan los motores, los usuarios virtuales y los límites?

Escalas una prueba añadiendo instancias de motor. En JMeter, la carga total es el número de usuarios del plan de prueba multiplicado por el número de motores; en Locust, fijas el total de usuarios y eliges cuántos motores los generan.

La página de conceptos da ambas fórmulas, y la página de límites del servicio fija los topes por región y suscripción (comprobado el 19 de octubre de 2026):

Instancias de motor por ejecución: de 1 a 400 por defecto según la oferta, 400 como máximo.
Instancias de motor simultáneas: de 5 a 400 por defecto, hasta 1.000 bajo petición.
Duración de la prueba: de 3 a 24 horas por defecto, 24 horas como máximo.
Criterios de fallo: hasta 50 por prueba.
Conservación: métricas de servidor 90 días, métricas de cliente 365 días, resultados y registros 6 meses.

Subir un límite por defecto exige una solicitud a soporte; nada supera los máximos indicados.

¿Puede probar endpoints privados y generar carga desde varias regiones?

Sí a ambas cosas, con una pega: no se combinan. La carga desde varias regiones solo funciona contra endpoints públicos.

Por defecto, los motores corren en la región de tu recurso de pruebas de carga. La guía de varias regiones permite elegir hasta 5 regiones por prueba y repartir la carga entre ellas, y al hacerlo pasa la prueba a tráfico público. Para servicios sin endpoint público, la inyección en una red virtual coloca los motores dentro de la red que aloja la aplicación (comprobado el 19 de octubre de 2026).

¿Qué muestran los resultados y las métricas de servidor?

El panel muestra en directo durante la ejecución las métricas del lado del cliente, como usuarios virtuales, tiempo de respuesta y peticiones por segundo. Para aplicaciones alojadas en Azure añade métricas del lado del servidor de Azure Monitor, Application Insights y Container Insights en la misma línea de tiempo.

Esa combinación es la gran ventaja del servicio: ves la base de datos o el contenedor que se satura en el momento en que suben los tiempos de respuesta, sin montar un panel aparte. La guía de métricas de servidor describe los pasos. Las ejecuciones anteriores se pueden comparar lado a lado, y puedes descargar los resultados para otras herramientas.

¿Cómo funcionan los criterios de aprobación y la CI?

Defines criterios de fallo sobre métricas de cliente o de servidor, y la ejecución se marca como fallida en cuanto se incumple alguno. Los pipelines de Azure DevOps, GitHub Actions o cualquier herramienta de CI que pueda llamar a la Azure CLI pueden lanzar una prueba y decidir según ese resultado.

Según la guía de criterios de fallo, un criterio es un agregado de una métrica de cliente, como el tiempo de respuesta medio o el porcentaje de errores, comparado con un umbral, ya sea para toda la prueba o para una petición con nombre. Las métricas de servidor necesitan que la identidad administrada del recurso pueda leerlas. La parada automática corta una ejecución cuando la tasa de errores supera un límite, para que una URL equivocada no siga costando dinero. La guía de CI/CD cubre GitHub Actions y Azure Pipelines (comprobado el 19 de octubre de 2026). Nuestra guía de criterios de aprobación en pruebas de carga explica cómo elegir los límites.

¿Cuánto cuesta Azure Load Testing?

Pagas por hora de usuario virtual (VUH): 0,15 $ por VUH las primeras 10.000 y 0,06 $ por VUH a partir de ahí, igual en todas las regiones de la página de precios. Desde el 1 de marzo de 2026 hay además un cobro mínimo por ejecución.

La página de precios define una VUH como usuarios virtuales por minutos, dividido entre 60, contado cada 10 segundos; 1.000 usuarios durante 30 minutos son 500 VUH, o 75 $ con la tarifa del primer tramo. El mínimo es de 10 usuarios virtuales por motor durante toda la ejecución, y al menos 10 minutos. Una ejecución de 3 horas con 5 usuarios en un motor se cobra por tanto como 30 VUH, no 15 (comprobado el 19 de octubre de 2026).

¿Cuándo conviene elegir otra cosa?

Elige otra opción cuando tus scripts, tu nube o tu presupuesto apunten a otro sitio.

Nuestro repaso de herramientas de pruebas de carga open source cubre las herramientas que puedes ejecutar tú mismo.

Elige LoadFocus, que publica este sitio, si quieres ejecutar planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube sin suscripción de Azure. No ejecuta Locust, y ejecuta los escenarios arrival-rate de k6 con un número fijo de usuarios.

Elige Grafana Cloud k6 o el k6-operator si tus pruebas están escritas para k6, que Azure Load Testing no puede ejecutar (comprobado el 19 de octubre de 2026).

Elige Locust en tu propia infraestructura si ya tienes Kubernetes o máquinas libres: su modo distribuido es gratis y solo pagas el hardware.

FAQ

¿Azure Load Testing admite k6? No. Ejecuta pruebas de Apache JMeter y de Locust, además de pruebas rápidas por URL que convierte él mismo en un script. Los scripts de k6 necesitan otro servicio o tu propia infraestructura.

¿Puedo usar Azure Load Testing con una aplicación que no está en Azure? Sí. Los motores de prueba pueden apuntar a cualquier endpoint público. Las métricas de servidor solo se recogen para recursos de Azure, así que con otro alojamiento lees las métricas de servidor en tu propia monitorización.

¿Hay un nivel gratuito? La página de precios solo muestra precios por hora para las pruebas de carga, con un mínimo por ejecución. Las cuentas nuevas de Azure reciben un crédito de 200 $ para sus primeros 30 días, según la misma página.

Lecturas relacionadas

Latencia de cola: qué es y cómo medirla

Mon, 19 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

La latencia de cola es el tiempo de respuesta de las pocas peticiones más lentas, que suele darse como el percentil 99 o 99,9. Importa porque una acción del usuario a menudo espera a muchas peticiones, así que un retraso que afecta a 1 petición de cada 100 puede llegar a la mayoría de tus usuarios. Una prueba de carga que solo muestra la media o la mediana no la refleja.

Llamadas al backend por página	Parte de las páginas con al menos una llamada lenta (1 de cada 100)
1	1,0 %
5	4,9 %
10	9,6 %
20	18,2 %
50	39,5 %
100	63,4 %

La tabla supone que cada llamada es lenta con un 1 % de probabilidad, con independencia de las demás: la parte es 1 - 0.99^n.

¿Qué se considera la cola?

La cola es la parte de la distribución de tiempos de respuesta por encima de un percentil alto, casi siempre p99 y p99,9. La mediana describe una petición típica, y la cola describe las peticiones de las que se queja la gente.

Un percentil es un corte: p99 = 800 ms significa que el 99 % de las peticiones tardó 800 ms o menos y el 1 % tardó más. En un histograma de tiempos de respuesta, la cola queda a la derecha de ese corte, a menudo como un tramo largo y fino lejos del pico principal. Nuestra guía de rendimiento vs latencia explica cómo miden la latencia y los percentiles las herramientas de pruebas de carga.

¿Por qué importa tanto la latencia de cola?

Porque las peticiones se multiplican. Una página o una llamada de API que se reparte entre muchos servicios solo termina cuando responde el más lento, así que la cola de cada servicio se convierte en la experiencia típica del conjunto.

La referencia es «The Tail at Scale», de Jeffrey Dean y Luiz André Barroso, publicado en Communications of the ACM en 2013 (PDF del artículo, comprobado el 19 de octubre de 2026). Su ejemplo: un servidor que suele responder en 10 ms pero tarda un segundo en el percentil 99. Si una petición toca uno de esos servidores, 1 de cada 100 peticiones de usuario es lenta. Si tiene que reunir respuestas de 100 en paralelo, el 63 % de las peticiones de usuario tarda más de un segundo. Incluso con solo 1 llamada lenta de cada 10.000, un servicio con 2.000 servidores ve casi 1 de cada 5 peticiones por encima del segundo.

También publican mediciones de un servicio real de Google: el percentil 99 de una sola petición hoja era de 10 ms, pero llegaba a 140 ms hasta que terminaban todas las peticiones hoja, y esperar al 5 % más lento suponía la mitad de ese tiempo.

¿Qué causa la latencia de cola?

Sobre todo interferencias de otro trabajo en la máquina o en la red. La misma petición es rápida casi siempre y lenta cuando está pasando otra cosa.

Dean y Barroso enumeran los sospechosos habituales:

Recursos compartidos: otro trabajo en la misma máquina que compite por núcleos de CPU, cachés del procesador, ancho de banda de memoria o de red.
Demonios en segundo plano que se despiertan y se llevan una parte de la máquina.
Tareas de mantenimiento como la compactación de registros o la recolección de basura en entornos gestionados.
Colas en servidores y conmutadores de red, que amplifican todas las demás fuentes.
Límites de potencia y temperatura que frenan una CPU tras un pico de trabajo.

En las pruebas de carga, la misma lista aparece como pausas de GC en servicios JVM o Node.js, un pool de conexiones agotado, una consulta lenta a la base de datos que solo disparan algunas peticiones, cachés frías tras un despliegue y reintentos después de un timeout. Una cola que crece con la carga apunta a colas de espera; una cola presente incluso con poca carga apunta a algo periódico, como el GC o una tarea programada.

¿Cómo se mide la latencia de cola en una prueba de carga?

Reúne suficientes muestras, pide a tu herramienta los percentiles adecuados y nunca promedies percentiles entre máquinas o ventanas de tiempo.

Suficientes muestras. El p99 lo decide el 1 % más lento de las peticiones, así que una ejecución de 500 peticiones lo apoya en 5 de ellas. Para un p99 estable necesitas miles de peticiones por transacción, y para el p99,9 decenas de miles. Las pruebas de humo cortas sirven para detectar errores y poco para juzgar la cola.

Los percentiles adecuados. Los valores por defecto suelen quedarse antes de la cola. En k6, summaryTrendStats es por defecto avg,min,med,max,p(90),p(95), así que el p99 solo aparece si lo añades (referencia de opciones de k6, comprobada el 19 de octubre de 2026):

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

El Aggregate Report de JMeter muestra las líneas del 90 %, 95 % y 99 %, y las propiedades aggregate_rpt_pct1 a aggregate_rpt_pct3 cambian qué percentiles aparecen (comprobado el 19 de octubre de 2026).

Nada de percentiles promediados. El p99 de una ejecución completa no es la media de los p99 de cada minuto ni la de los p99 de cada generador de carga. Junta las muestras en bruto o un histograma y calcula el percentil una sola vez. El artículo sobre coordinated omission trata HdrHistogram, la herramienta habitual para eso, y una segunda trampa: un generador de carga que espera las respuestas lentas envía menos peticiones mientras el sistema va lento, y esconde justo la cola que buscas.

LoadFocus, que publica este sitio, muestra en cada ejecución las tarjetas P95 y P99, un histograma de tiempos de respuesta construido a partir de las muestras individuales y las peticiones más lentas, de modo que una cola larga a la derecha del pico se ve de un vistazo.

¿Cómo se fija un límite de aprobación para la cola?

Pon un límite al p99 de cada transacción clave, junto a un límite de p95 y otro de tasa de errores. Básalo en lo que necesitan los usuarios de esa transacción y haz que la ejecución dure lo suficiente para que el p99 sea estable.

Un conjunto razonable para una API de pago podría ser: p95 por debajo de 400 ms, p99 por debajo de 1.200 ms y errores por debajo del 0,5 %. En k6 son umbrales sobre http_req_duration como p(99)<1200, y un umbral superado hace que k6 termine con un código distinto de cero (umbrales de k6, comprobado el 19 de octubre de 2026). LoadFocus tiene un campo Max P99 response time junto a Max P95 para pruebas cloud, JMeter y k6, y cada ejecución recibe entonces un PASS o un FAIL. Nuestra guía de criterios de aprobación en pruebas de carga cubre el resto del conjunto.

Si además informas de una puntuación Apdex, recuerda que mete toda petición por encima de cuatro veces T en la misma franja, así que no distingue una cola de 2 segundos de una de 30. El p99 sí.

¿Cómo se reduce la latencia de cola?

Elimina las fuentes de variabilidad donde puedas y diseña los clientes para que una llamada lenta no retenga toda la respuesta.

Arreglos habituales, más o menos del más barato al más costoso:

Ajusta el GC y el tamaño de los pools para que las pausas y la espera de una conexión libre sigan siendo cortas bajo carga.
Deja margen. Las colas de espera crecen de golpe cerca de la saturación, así que la capacidad libre acorta la cola; la guía de rendimiento vs latencia muestra cómo encontrar el codo.
Pon timeouts y limita los reintentos para que una llamada atascada falle rápido en lugar de acumular todo lo que viene detrás.
Usa peticiones de cobertura (hedged requests) en lecturas idempotentes: envía una segunda copia a otra réplica si la primera no ha respondido a tiempo. Dean y Barroso describen enviar la copia solo después de la latencia esperada del percentil 95, lo que limita la carga extra a un 5 % aproximadamente. En una de sus pruebas, una copia enviada a los 10 ms bajó el percentil 99,9 de 1.800 ms a 74 ms con solo un 2 % más de peticiones.
Reduce el fan-out. Menos llamadas al backend por página significa menos ocasiones de caer en la cola, como muestra la tabla del principio.

Tras cada cambio, repite la misma prueba con el mismo perfil de carga y compara p99 y p99,9 entre ejecuciones.

FAQ

¿La latencia de cola es lo mismo que el p99? El p99 es la forma más común de expresarla, y la cola es todo el extremo lento de la distribución. Sigue también el p99,9 y el máximo cuando la ejecución tenga suficientes peticiones.

¿Por qué mi p99 es tan superior a mi media? Porque unas pocas peticiones lentas apenas mueven la media y definen por completo el p99. Una diferencia grande es normal; una diferencia que crece con la carga suele indicar colas de espera.

¿Cuántas peticiones necesito para medir el p99? Como mínimo unos miles por transacción, para que el p99 se apoye en decenas de peticiones lentas. Para el p99,9, cuenta con decenas de miles.

Lecturas relacionadas

Pruebas de carga gRPC: herramientas, configuración, métricas

Fri, 16 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Una prueba de carga gRPC necesita una herramienta que hable HTTP/2 y Protocol Buffers: k6 y ghz lo hacen de serie, JMeter necesita un plugin, el soporte gRPC de Gatling está limitado en su edición gratuita y en Locust tienes que integrar tú mismo un cliente gRPC. Cuenta los resultados por estado gRPC, no por estado HTTP, porque las llamadas fallidas siguen llegando como HTTP 200, y comprueba que la carga llega a todos los backends.

Para este artículo no se ejecutó ninguna prueba gRPC. Los datos sobre herramientas salen de la documentación y los repositorios de cada proyecto, comprobados el 16 de octubre de 2026; los datos sobre LoadFocus salen de su código.

Herramienta	Soporte gRPC	Lee la API desde	Control del ritmo
k6	Integrado (`k6/net/grpc`), llamadas unarias y streams	Archivos `.proto` o reflexión del servidor	Ejecutores arrival-rate
ghz	Herramienta de línea de comandos dedicada a gRPC	`.proto`, protoset o reflexión del servidor	`--rps` y planes de carga
JMeter	Plugin de terceros (jmeter-grpc-request)	Una carpeta de archivos `.proto`	Thread Groups y temporizadores
Gatling	Componente gRPC aparte; edición gratuita limitada a 5 usuarios, 5 minutos	Código generado desde los `.proto` con protoc	Perfiles de inyección
Locust	Sin cliente integrado; envuelve uno y reporta las llamadas	Tu cliente gRPC de Python	Tiempos de espera, `constant_throughput`

¿Por qué gRPC necesita una prueba de carga distinta de REST?

gRPC va sobre HTTP/2, envía Protocol Buffers binarios en lugar de JSON, pone el resultado de la llamada en un trailer en vez de en el estado HTTP y multiplexa muchas llamadas sobre una sola conexión. Cada una de esas cosas cambia cómo escribes la prueba o lees sus resultados.

El artículo sobre balanceo de carga en gRPC enumera las características de HTTP/2 que importan aquí: un protocolo binario, muchas peticiones multiplexadas en una conexión y compresión de cabeceras, con mensajes Protobuf fuertemente tipados encima (comprobado el 16 de octubre de 2026). Una herramienta que solo envía JSON sobre HTTP/1.1 no puede llamar a un método gRPC, así que comprueba primero el soporte del protocolo.

¿Qué herramienta deberías usar?

Usa k6 si quieres escenarios, checks y umbrales escritos en código; usa ghz para un benchmark rápido de un método desde la línea de comandos. Recurre a JMeter, Gatling o Locust cuando tu equipo ya hace todo lo demás con ellos.

k6. El módulo k6/net/grpc carga definiciones Protobuf, se conecta, hace llamadas unarias con invoke y abre streams. Reporta grpc_req_duration y el número de mensajes de los streams en sus métricas.
ghz. Una herramienta de benchmark de línea de comandos solo para gRPC. Sus opciones incluyen --rps, --concurrency, --total y --duration, y si no pasas ni --proto ni --protoset intenta la reflexión del servidor. La última versión es v0.121.0 (comprobado el 16 de octubre de 2026).
JMeter. El núcleo de JMeter no tiene sampler gRPC; el plugin jmeter-grpc-request añade uno que lee una carpeta de archivos .proto, sin generar código (última etiqueta v1.2.6, comprobado el 16 de octubre de 2026).
Gatling. El README de Gatling pone gRPC, MQTT y GraphQL bajo la Gatling Enterprise Component License, limitados en Community Edition a 5 usuarios simultáneos y pruebas de 5 minutos (comprobado el 16 de octubre de 2026). Su guía de configuración de gRPC genera código a partir de tus archivos .proto con protoc.
Locust. Su documentación sobre probar otros sistemas incluye un ejemplo de gRPC: envuelves un cliente gRPC para que cada llamada se reporte a Locust, y constant_throughput limita una tarea a un número máximo de ejecuciones por segundo.

Elige ghz en lugar de k6 cuando solo necesitas saber cómo se comporta un método a un ritmo dado y no quieres escribir un script. Elige Locust en su lugar cuando tu equipo escribe en Python y la prueba necesita lógica que resulta más fácil ahí.

¿Cómo se escribe una prueba de carga gRPC en k6?

Carga el archivo .proto en el código de inicialización y, en cada iteración, conéctate, llama al método y comprueba el estado gRPC. La estructura sigue el ejemplo de la documentación de k6.

import grpc from 'k6/net/grpc';
import { check } from 'k6';

const client = new grpc.Client();
client.load(['protos'], 'hello.proto');

export const options = { vus: 20, duration: '1m' };

export default () => {
  client.connect('grpc.example.com:443');
  const res = client.invoke('hello.Greeter/SayHello', {
    name: 'load test',
  });
  check(res, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
};

La página de invoke usa la misma secuencia de carga, conexión, llamada, comprobación y cierre. connect usa TLS salvo que pases plaintext: true, y con reflect: true pide su API al servidor en lugar de leer un archivo .proto (parámetros de conexión). Para mantener un ritmo de peticiones en vez de un número de usuarios, ejecuta la función en un escenario arrival-rate.

¿Cómo se hace un benchmark rápido con ghz?

Indica a ghz el método, un cuerpo de petición y un ritmo o una concurrencia, y muestra un histograma de latencia, percentiles y un recuento por código de estado. Sirve para un primer vistazo a un método.

ghz --insecure --proto ./hello.proto \
  --call hello.Greeter.SayHello \
  -d '{"name":"load test"}' \
  --rps 200 -c 50 -z 1m \
  localhost:50051

--rps fija el ritmo objetivo, repartido entre los workers, -c cuántos workers hay y -z la duración. Quita --proto para que ghz use la reflexión del servidor, si el servidor la tiene activada. La página de salida de ghz muestra un informe de ejemplo.

¿Qué deberías medir en una prueba de carga gRPC?

Mide los percentiles de latencia de las llamadas, el rendimiento y el número de cada código de estado gRPC. Una tasa de éxito a nivel HTTP puede marcar 100 % mientras las llamadas fallan, porque el resultado viaja en el trailer grpc-status.

La especificación de gRPC sobre HTTP/2 fija el estado HTTP en :status 200 y lleva el resultado de la llamada en trailers como grpc-status y grpc-message. La lista de códigos de estado tiene los que más importan bajo carga:

DEADLINE_EXCEEDED (4): el plazo venció antes de que terminara la llamada.
RESOURCE_EXHAUSTED (8): se agotó una cuota o un recurso.
INTERNAL (13): se rompió un invariante interno, un código reservado para errores graves.
UNAVAILABLE (14): suele ser pasajero; reintentar con backoff puede resolverlo, aunque no siempre es seguro en llamadas no idempotentes.

Cuenta cada uno por escalón de carga. Los errores de plazo pueden subir mientras las llamadas que tienen éxito aún parecen rápidas, porque las lentas se cortan en el plazo en lugar de registrarse como lentas. Nuestra guía de criterios de aprobación en pruebas de carga muestra cómo convertir esos recuentos en umbrales.

¿Por qué toda la carga cae en un solo servidor?

Porque gRPC multiplexa muchas llamadas sobre una conexión de larga duración, un balanceador que trabaja por conexión envía cada llamada de esa conexión al mismo backend. Un generador de carga con pocas conexiones puede entonces saturar un servidor mientras los demás están parados.

El artículo sobre balanceo de carga en gRPC explica el mecanismo. Un balanceador a nivel de transporte (L3/L4) termina la conexión TCP y abre otra hacia un backend elegido, copiando las tramas HTTP/2 y gRPC entre ambas; un balanceador a nivel de aplicación (L7) analiza HTTP/2 y puede repartir los streams de una misma conexión de cliente entre varios backends. Si tus clientes de producción pasan por un balanceador L7 o balancean del lado del cliente, prueba por el mismo camino y revisa la CPU y el número de peticiones de cada backend durante la ejecución.

¿Se pueden ejecutar pruebas de carga gRPC en LoadFocus?

No de forma que sus informes lo muestren. LoadFocus ejecuta la versión estándar de k6 v0.57.0, que incluye el módulo gRPC, pero su agente de k6 solo envía a los resultados las muestras de peticiones HTTP, así que las llamadas gRPC generarían carga sin aparecer en sus gráficos ni en sus recuentos de errores.

Hay dos límites más. La subida de archivos de k6 acepta archivos .js, .ts, .csv, .txt, .json, .env y .properties, no archivos .proto, así que un script tendría que conectarse con reflect: true. Y la vía de JMeter está cerrada: los agentes de JMeter de LoadFocus traen JMeter 5.6.2 con plugins preinstalados que no incluyen un sampler gRPC, y la subida de JMeter no acepta archivos JAR de plugins. Para gRPC, ejecuta k6 o ghz en tus propias máquinas y usa los scripts de k6 en LoadFocus para la parte HTTP del mismo sistema, donde genera carga desde 25 regiones.

FAQ

¿Se pueden hacer pruebas de carga de llamadas gRPC en streaming? Sí, con k6 y ghz. El módulo gRPC de k6 tiene una clase Stream con write, end y manejadores de eventos, y ghz tiene opciones para intervalos y duraciones de streaming. Mide los mensajes enviados y recibidos además de la latencia de las llamadas.

¿Hace falta el archivo .proto para hacer una prueba de carga de un servicio gRPC? No si el servidor tiene la reflexión activada. k6 puede conectarse con reflect: true, y ghz recurre a la reflexión cuando no pasas ni --proto ni --protoset. Sin reflexión necesitas el archivo .proto o un protoset compilado.

¿Por qué mis errores gRPC no aparecen como peticiones fallidas? Porque el estado HTTP de una llamada gRPC es 200 aunque la llamada falle. El resultado está en el trailer grpc-status, así que comprueba ese valor en tu script y cuenta cada código por separado.

Lecturas relacionadas

Rendimiento vs latencia: cómo se relacionan bajo carga

Fri, 16 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

El rendimiento (throughput) es la cantidad de trabajo que un sistema termina por unidad de tiempo, por ejemplo peticiones por segundo. La latencia es lo que tarda una unidad de trabajo, por ejemplo 120 milisegundos por petición. Con poca carga apenas se afectan entre sí; cuando la carga se acerca a la capacidad del sistema, el rendimiento deja de subir y la latencia empieza a crecer, y encontrar ese punto es justo para lo que sirve una prueba de carga.

El ejemplo de abajo es aritmética, sin ninguna prueba detrás. Las definiciones de las herramientas salen de la documentación de cada proyecto, comprobada el 16 de octubre de 2026.

	Rendimiento	Latencia	Ancho de banda
Pregunta que responde	¿Cuánto se termina por segundo?	¿Cuánto tarda una unidad?	¿Cuánto podría llevar el enlace?
Unidad habitual	peticiones o transacciones por segundo	milisegundos	megabits por segundo
En k6	`http_reqs` (cuenta y tasa)	`http_req_duration`	no es un objetivo de la prueba
En JMeter	Throughput	Elapsed time (y una "Latency" aparte)	no es un objetivo de la prueba

¿Qué diferencia hay entre rendimiento y latencia?

El rendimiento cuenta el trabajo terminado a lo largo del tiempo; la latencia mide lo que tarda una unidad de trabajo. Un sistema puede tener latencia baja y rendimiento bajo, o rendimiento alto y latencia alta, así que necesitas las dos cifras para describirlo.

El glosario de JMeter calcula el rendimiento como el número de peticiones dividido entre el tiempo total, desde el inicio de la primera muestra hasta el final de la última, incluidas las pausas entre muestras, porque debe representar la carga sobre el servidor (comprobado el 16 de octubre de 2026). Eso hace del rendimiento una propiedad de toda la ejecución, mientras que la latencia pertenece a cada petición y se lee mejor como una distribución: mediana, p95, p99.

¿El ancho de banda es lo mismo que el rendimiento?

No. El ancho de banda es la cantidad máxima de datos que podría llevar un enlace de red; el rendimiento es lo que pasa de verdad. En una prueba de carga, el rendimiento suele referirse a peticiones terminadas, y el ancho de banda solo importa cuando cargas de datos grandes llenan el enlace antes de que la aplicación agote su capacidad.

La página comparativa de AWS resume la visión de red: la latencia es el retraso en la comunicación de red, el rendimiento es el volumen medio de datos que realmente pasa en un periodo y el ancho de banda es el máximo teórico (comprobado el 16 de octubre de 2026). Buena parte de lo que se encuentra en internet usa ese sentido de red. Las pruebas de carga usan las mismas palabras para peticiones en lugar de paquetes, y por eso conviene decir cuál de los dos significa un informe.

¿Qué significa "latencia" en una herramienta de pruebas de carga?

Depende de la herramienta. En JMeter, Latency es el tiempo hasta la primera parte de la respuesta, y el tiempo de respuesta completo se llama Elapsed time. En k6, http_req_duration abarca el envío, la espera y la recepción, y el tiempo hasta el primer byte es una métrica aparte.

El glosario de JMeter mide el Elapsed time desde justo antes de enviar la petición hasta justo después de recibir la última respuesta, y la Latency hasta justo después de recibir la primera. La referencia de métricas de k6 define http_req_duration como http_req_sending + http_req_waiting + http_req_receiving, sin la resolución DNS ni el establecimiento de la conexión, y llama a http_req_waiting el tiempo hasta el primer byte (ambos comprobados el 16 de octubre de 2026). Así que la Latency de JMeter equivale a http_req_waiting de k6, no a http_req_duration. Si comparas una "latencia" de JMeter con una "duration" de k6, la cifra de JMeter parecerá mejor sin serlo.

¿Cómo cambian el rendimiento y la latencia al crecer la carga?

Al principio, más carga significa más rendimiento, y la latencia se mantiene más o menos plana. Cuando el sistema llega a su capacidad, el rendimiento deja de crecer y cada usuario adicional solo añade espera, así que la latencia sube con la carga.

Un ejemplo, solo aritmética. Un servicio atiende como mucho 200 peticiones por segundo y responde en 0,1 segundos cuando no está ocupado. Cada usuario virtual envía una petición y luego hace una pausa de 1 segundo. Con un número fijo de usuarios, la forma de la ley de Little para el modelo cerrado los relaciona: usuarios = peticiones por segundo × (latencia + tiempo de reflexión), como muestra paso a paso nuestro artículo sobre la ley de Little.

Usuarios virtuales	Rendimiento (peticiones/s)	Latencia (s)
50	45	0,1
150	136	0,1
220	200	0,1
300	200	0,5
400	200	1,0
600	200	2,0

Hasta 220 usuarios, el rendimiento crece al mismo ritmo que ellos. A partir de ahí se queda fijo en 200, y la latencia tiene que absorber el resto: 300 usuarios necesitan 300 ÷ 200 = 1,5 segundos por vuelta, lo que deja 0,5 segundos de latencia. Los sistemas reales suelen curvarse de forma más gradual, porque las colas empiezan a formarse antes del techo exacto. Con una prueba de tasa de llegada el panorama es más duro: si las peticiones llegan a más de 200 por segundo, la acumulación crece mientras dure el exceso, que es la diferencia que explica el artículo sobre el modelo de carga abierto vs cerrado.

¿Cómo encuentras el codo en tus propios resultados?

Sube la carga por escalones, mantén cada escalón lo suficiente para que se estabilice y anota el rendimiento y un percentil de latencia de cada uno. El codo es el primer escalón en el que el rendimiento deja de subir con la carga mientras la latencia empieza a crecer.

Algunas cosas hacen fiable esa lectura:

Mantén cada escalón unos minutos, para medir el rendimiento en un tramo estable y no en una rampa.
Lee un percentil, no solo la media; la media puede seguir tranquila mientras el pequeño porcentaje de peticiones más lentas se vuelve mucho más lento.
Revisa los errores en cada escalón. Los fallos rápidos cuentan como peticiones terminadas con tiempos cortos, así que un sistema que falla puede mostrar más rendimiento y menos latencia.
Vigila el generador de carga. Si su CPU está saturada, el techo que encontraste puede ser el suyo.

El gráfico de tiempo de respuesta frente a usuarios virtuales de LoadFocus muestra el tiempo de respuesta medio y máximo frente a los usuarios virtuales activos, un punto por cada nivel alcanzado, y ahí es donde aparece el codo en una prueba por escalones.

¿Se puede subir el rendimiento sin subir la latencia?

A veces. Añadir capacidad mueve el techo, así que la latencia se mantiene plana más tiempo. Agrupar trabajo (batching) suele hacer la concesión contraria: sube el rendimiento haciendo esperar a cada petición.

El algoritmo de Nagle de TCP es el ejemplo clásico de esa concesión. La RFC 896 retiene los segmentos nuevos mientras haya datos enviados en la conexión sin confirmar, de modo que la red lleva menos paquetes y más llenos, y cada escritura pequeña puede esperar (comprobado el 16 de octubre de 2026). Agrupar peticiones y usar búferes de escritura funciona igual: más trabajo por segundo, más tiempo por elemento. Cuando cambies algo de esto, repite la prueba por escalones y compara las dos curvas, no una sola cifra.

¿Cuál de los dos va en tus criterios de aprobación?

Los dos, unidos. Un objetivo de latencia dice poco sin el rendimiento con el que se midió, y un objetivo de rendimiento dice poco si la latencia se duplicó para alcanzarlo. Exprésalos como una pareja, por ejemplo p95 por debajo de 300 milisegundos a 200 peticiones por segundo con menos de un 1 % de errores.

Nuestra guía de criterios de aprobación en pruebas de carga muestra cómo escribir y automatizar esa pareja. Si tu herramienta espera a las respuestas lentas antes de enviar la siguiente petición, sus cifras de latencia pueden quedarse cortas; la coordinated omission explica cómo ocurre y cómo evitarla. La entrada del glosario de LoadFocus sobre la latencia explica de dónde viene la latencia y por qué importan los percentiles.

FAQ

¿Una latencia baja significa un rendimiento alto? No necesariamente. Un sistema puede responder rápido a cada petición pero atender pocas a la vez, o atender muchas a la vez mientras cada una espera. Solo conoces las dos cosas después de medirlas bajo la misma carga, idealmente en varios niveles de carga.

¿Qué diferencia hay entre latencia y tiempo de respuesta? En el uso cotidiano suelen significar lo mismo. En JMeter, Latency es el tiempo hasta la primera parte de la respuesta y Elapsed time el tiempo de respuesta completo, así que comprueba cuál muestra un informe antes de comparar herramientas.

¿Por qué deja de subir el rendimiento en una prueba de carga? Algo ha llegado a su límite: la CPU, una base de datos, un pool de conexiones, un límite de peticiones (rate limit) o el propio generador de carga. A partir de ahí, los usuarios adicionales solo hacen cola, lo que se ve como latencia en aumento con el rendimiento plano.

Lecturas relacionadas

Gatling vs Locust: ¿simulaciones JVM o locustfiles Python?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Gatling y Locust son dos herramientas open source gratuitas que guardan las pruebas de carga como código en tu repositorio. Elige Gatling si tu equipo trabaja en la JVM o si quieres perfiles de inyección abiertos y cerrados, aserciones y un informe HTML en un solo paquete. Elige Locust si tu equipo escribe Python, valora una interfaz web para iniciar y seguir una ejecución, y necesita el modo distribuido sin una edición comercial.

Los datos de esta comparación Gatling vs Locust salen de la documentación y del repositorio de cada proyecto, comprobados el 13 de octubre de 2026.

	Gatling	Locust
Licencia	Apache 2.0; gRPC, MQTT y GraphQL con una licencia de componente aparte (repositorio)	MIT (repositorio)
Entorno de ejecución	JVM, OpenJDK LTS 11 a 25 (versión 3.16.0)	Python 3.11 o posterior (versión 2.46.7)
Código de prueba	Java, Kotlin, Scala, JavaScript o TypeScript	Python
Protocolos integrados	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP y HTTPS; otros mediante un cliente de Python
Modelo de carga	Perfiles de inyección abiertos o cerrados	Un pool de usuarios, es decir, un modelo cerrado
Criterios de aprobación	Aserciones, evaluadas después de la ejecución	Código de salida 1 si fallan peticiones, o tu propio listener
Informes	Informe HTML después de cada ejecución	Gráficos en vivo en la interfaz web, archivos CSV, informe HTML
Escalado	Gatling Enterprise	Modo master y workers integrado, operador de Kubernetes

¿Cuál es la diferencia entre Gatling y Locust?

Gatling ejecuta simulaciones en la JVM y Locust ejecuta programas de Python normales. Gatling trae de serie un modelo de carga y un informe, y en Locust escribes tú mismo la lógica de la prueba.

El README de Gatling describe un motor no bloqueante construido sobre Netty y un SDK en cinco lenguajes: Java, Kotlin y Scala se ejecutan con Maven, Gradle o sbt, y JavaScript y TypeScript con un SDK aparte. Su página de instalación pide un OpenJDK LTS de 64 bits de la 11 a la 25, y Node.js 24 o posterior para el SDK de JavaScript.

El README de Locust lo presenta como una forma de escribir pruebas de carga escalables en Python puro, y sus metadatos del paquete exigen Python 3.11 o posterior. La página What is Locust dice que se basa en eventos con gevent, así que un solo proceso puede manejar muchos miles de usuarios concurrentes (comprobado el 13 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

En Gatling encadenas peticiones en un escenario y le das un perfil de inyección. En Locust escribes una clase de usuario con tareas y un tiempo de espera entre ellas.

Cincuenta usuarios concurrentes que listan usuarios y luego esperan de uno a tres segundos, durante cinco minutos. Con el SDK de Java de Gatling (imports omitidos):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

La misma prueba en Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

La referencia de inyección de Gatling incluye constantConcurrentUsers entre los pasos del modelo cerrado. Locust recibe el número de usuarios y la duración como opciones (comprobado el 13 de octubre de 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

¿Cómo modelan la carga Gatling y Locust?

Gatling ofrece modelos abiertos y cerrados, según el método que llames. Locust ejecuta un pool de usuarios, lo que equivale a un modelo cerrado.

La página de modelos de carga de Gatling define los sistemas cerrados como los que limitan los usuarios concurrentes, y los abiertos como aquellos en los que los usuarios siguen llegando aunque la aplicación responda despacio. Añade que la mayoría de los sitios web son abiertos. injectOpen recibe tasas de llegada e injectClosed objetivos de concurrencia.

La guía del locustfile dice que el tiempo de espera solo puede limitar el rendimiento y no lanza usuarios nuevos para alcanzar una tasa objetivo. Si una vuelta tarda más de lo que permite la espera, la tasa queda por debajo del objetivo (comprobado el 13 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica por qué importa.

¿Cómo se ejecuta una prueba mayor de lo que genera una sola máquina?

Locust trae el modo distribuido integrado. La edición open source de Gatling genera carga desde una sola máquina, y las ejecuciones distribuidas requieren Gatling Enterprise.

Locust arranca un proceso con --master y tantos procesos --worker como quieras. Según los docs de carga distribuida, un proceso de Python no usa más de un núcleo, así que se ejecuta un worker por núcleo, y --processes arranca varios en una máquina. Un operador de Kubernetes gestiona las ejecuciones distribuidas dentro de un clúster.

Las preguntas frecuentes de Gatling dicen que la Community Edition no admite pruebas distribuidas, y el README describe Enterprise como una ejecución en generadores de carga gestionados o en infraestructura privada (comprobado el 13 de octubre de 2026).

Hay una salida para ambas. LoadFocus, que publica este sitio, no ejecuta simulaciones de Gatling ni pruebas de Locust. Si prefieres no ejecutar ninguna de las dos a gran escala, ejecuta scripts de k6 y planes de prueba de JMeter desde 25 regiones en la nube. Su validador de k6 avisa de que los escenarios de tasa de llegada se ejecutan allí con un número fijo de usuarios, así que no mantienen un ritmo de peticiones. Pasar de cualquiera de las dos herramientas a esas obliga a reescribir la prueba.

¿Cómo deciden si una prueba ha pasado, y qué informes obtienes?

Gatling evalúa las aserciones después de la ejecución y escribe un informe HTML cada vez. Locust termina con el código 1 si falló alguna petición, y otras comprobaciones las añades como listener.

Las aserciones de Gatling se evalúan después de la simulación, y una sola aserción fallida hace fallar la simulación. Su informe HTML muestra percentiles del tiempo de respuesta, usuarios iniciados por segundo, usuarios concurrentes y peticiones por segundo.

Según los docs headless de Locust, la ejecución termina con el código 1 si alguna muestra falló, y un ejemplo de listener hace fallar la ejecución por el ratio de fallos, el tiempo de respuesta medio o el percentil 95. La referencia de configuración menciona --csv para archivos de estadísticas y --html para un informe (comprobado el 13 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

Gatling trae más protocolos, con límites en los más nuevos. Locust trae HTTP y HTTPS y espera un cliente de Python para el resto.

El README de Gatling enumera HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS bajo Apache 2.0 sin límites. gRPC, MQTT y GraphQL están bajo la Gatling Enterprise Component License, y las pruebas con ellos quedan limitadas a 5 usuarios concurrentes y 5 minutos en la Community Edition.

La página sobre otros sistemas de Locust muestra cómo envolver una librería de protocolo y notificar cada llamada, con ejemplos de gRPC y MQTT. La librería tiene que funcionar con gevent, que no puede parchear la E/S hecha en código C compilado, y locust-plugins añade usuarios para Kafka, Selenium y Playwright (comprobado el 13 de octubre de 2026).

¿Cuál deberías elegir?

Elige según el lenguaje y la forma de cargar el sistema. Gatling encaja con equipos JVM y pruebas en modelo abierto, y Locust con equipos Python y pruebas con lógica propia.

Elige Gatling en lugar de Locust si tu equipo vive en la JVM y quiere pruebas en Java, Kotlin o Scala construidas con Maven, Gradle o sbt, si necesitas un modelo abierto como una tasa de llegada fija, si necesitas JMS o Server-Sent Events, o si quieres aserciones y un informe sin código adicional.

Elige Locust en lugar de Gatling si tu equipo escribe Python y quiere que las pruebas reutilicen un cliente interno de Python, si quieres una interfaz web para iniciar una ejecución y cambiar la carga mientras corre, si necesitas el modo distribuido en la herramienta gratuita, o si el sistema recibe sobre todo usuarios que esperan y tu protocolo tiene una librería de Python compatible con gevent.

Para un constructor de pruebas con interfaz gráfica mira JMeter, y para un solo binario sin JVM ni Python mira k6.

FAQ

¿Es Gatling más rápido que Locust? No lo hemos medido nosotros, así que no vamos a nombrar un ganador. La comparación justa es el mismo escenario con las dos herramientas en tu propio hardware.

¿Puede Locust ejecutar simulaciones de Gatling? No según la documentación de Locust, que describe las pruebas solo como código Python. Una simulación de Gatling hay que reescribirla como locustfile, y lo mismo vale a la inversa.

¿Puede LoadFocus ejecutar pruebas de Gatling o de Locust? No. LoadFocus ejecuta planes de prueba de JMeter y scripts de k6. Para repartir una simulación de Gatling entre varias máquinas usa Gatling Enterprise, y para Locust su modo master y workers o su operador de Kubernetes.

Lecturas relacionadas

JMeter vs Postman: ¿qué herramienta para pruebas de carga?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Postman es un cliente de API pensado para comprobaciones funcionales, colecciones y trabajo en equipo, al que se ha añadido un modo de pruebas de rendimiento. Apache JMeter es un generador de carga desde el principio. Usa Postman si quieres reutilizar la colección que ya tienes para una prueba de carga rápida o un smoke test en CI. Usa JMeter cuando la prueba de carga es el trabajo principal: muchos protocolos, grandes cantidades de usuarios, informes detallados y generación de carga distribuida.

Los datos sobre Postman salen de su documentación y de su página de precios, y los de JMeter del sitio del propio proyecto, todos comprobados el 13 de octubre de 2026.

	Postman	Apache JMeter
Propósito principal	Cliente de API, pruebas funcionales y de colecciones, con modo de rendimiento	Pruebas de carga y de rendimiento
Definición de la prueba	Una colección de peticiones con scripts y aserciones `pm.test()`	Un plan de prueba creado en una GUI y guardado como archivo `.jmx`
Usuarios virtuales	Cada uno ejecuta la colección en bucle; las ejecuciones locales las limita tu máquina	Un hilo de Java por usuario en un Thread Group
Perfiles de carga	Fixed, Ramp up, Spike y Peak	Thread Groups con periodo de rampa
De dónde viene la carga	Tu máquina o un runner de CI, o la nube de Postman en planes de pago	Tu máquina, o servidores JMeter remotos que gestionas tú
Coste de la carga	Ejecuciones locales en todos los planes; ejecuciones en la nube a 0,04 $ por hora de usuario virtual	Gratis, licencia Apache 2.0
Aprobado o suspendido en CI	`postman performance run` con `--pass-if`	Modo CLI (`jmeter -n`)

¿Qué hacen las pruebas de rendimiento de Postman?

Ejecutan las peticiones de una colección con varios usuarios virtuales en paralelo, durante un número de minutos fijado. Cada usuario repite las peticiones en orden, y tus scripts y aserciones actuales se ejecutan bajo carga.

Según la documentación de pruebas de rendimiento, la colección de tus pruebas funcionales es también tu prueba de carga, sin un script ni un lenguaje aparte que mantener (comprobado el 13 de octubre de 2026). Eliges una duración y un número de usuarios virtuales, y luego un perfil Fixed, Ramp up, Spike o Peak, como describe la página de configuración.

¿Cuáles son los límites de Postman para pruebas de carga?

El límite principal es de dónde viene la carga. Una ejecución local queda limitada por la máquina que la lanza, y lo que vaya más allá requiere un plan de pago.

Para las ejecuciones locales, la documentación de Postman dice que el número de usuarios virtuales depende de los recursos del sistema y de la colección usada, que los scripts de pre-request y post-response reducen los usuarios que se pueden simular, y que la ejecución se detiene si la máquina supera su umbral de recursos. Sugiere una primera prueba de 10 a 20 usuarios virtuales (comprobado el 13 de octubre de 2026). Pasado ese punto, el propio generador de carga puede distorsionar tus medidas, y por eso Postman muestra también los picos de CPU y memoria de la máquina de prueba.

Los datos son el siguiente límite. Según la misma página de configuración, los archivos de datos CSV y JSON solo funcionan en ejecuciones locales, mientras que los datasets funcionan en locales y en la nube.

¿Cuánto cuesta hacer pruebas de carga con Postman?

Las ejecuciones de rendimiento locales van incluidas en todos los planes. Las ejecuciones en la nube son para planes de pago y se facturan por uso, en horas de usuario virtual.

La página de precios de Postman indica pruebas de rendimiento locales ilimitadas y pruebas de rendimiento en la nube a 0,04 $ por hora de usuario virtual (comprobado el 13 de octubre de 2026). A esa tarifa publicada, 500 usuarios virtuales durante una hora son 500 horas de usuario virtual, es decir, 20 $, además de la cuota del plan. Las direcciones IP estáticas para llegar a destinos tras un cortafuegos son una función de Enterprise. No hemos valorado los planes en sí: consulta la página para las cuotas actuales por usuario.

¿Qué protocolos se pueden probar?

JMeter tiene una lista larga y documentada. Para Postman no hemos encontrado una lista de protocolos admitidos en las ejecuciones de rendimiento, así que no afirmamos nada al respecto.

La página principal de JMeter cita HTTP y HTTPS, SOAP y REST, FTP, bases de datos mediante JDBC, LDAP, mensajería JMS, correo SMTP, POP3 e IMAP, comandos nativos y scripts de shell, TCP y objetos Java (comprobado el 13 de octubre de 2026). Postman maneja en la aplicación otros tipos de petición, como GraphQL, gRPC y WebSocket, pero eso no dice cuáles se ejecutan bajo carga. Prueba uno antes de depender de él.

¿Cómo se escala más allá de una máquina?

Postman escala con su propia nube, JMeter con servidores que gestionas tú. Lo primero es más fácil de empezar, lo segundo te da control.

En un plan de pago, las ejecuciones en la nube de Postman reparten la carga entre workers gestionados, de modo que una sola máquina deja de limitar la prueba. El modo de pruebas remotas de JMeter permite que un cliente controle muchos servidores JMeter. Todos los nodos necesitan la misma versión de JMeter, un keystore para RMI sobre SSL salvo que lo desactives, y su propia copia de los archivos de datos (comprobado el 13 de octubre de 2026).

Hay una tercera vía para los planes de prueba de JMeter. LoadFocus, el editor de este sitio, ejecuta tus planes de prueba de JMeter existentes desde 25 regiones en la nube. Subes el archivo .jmx y fijas usuarios virtuales, duración y rampa, sin servidores remotos que configurar. LoadFocus solo ejecuta JMeter y k6, así que no ejecuta una colección de Postman.

¿Qué herramienta deberías elegir?

Elige Postman en lugar de JMeter para comprobaciones funcionales y de contrato, para un equipo que comparte colecciones en un espacio de trabajo y para una ejecución rápida de humo de una API que ya pruebas. Elige JMeter cuando la prueba de carga es el objetivo principal, o cuando necesitas varios protocolos, muchos usuarios o pruebas que viven en tu propio repositorio.

Postman encaja en una comprobación corta en CI: postman performance run termina con un código de salida distinto de cero cuando se incumple un umbral como el percentil 95, lo que hace fallar la compilación. JMeter es mejor para carga sobre bases de datos o mensajería, para pruebas de resistencia largas y para el panel HTML con tablas APDEX y de percentiles que describe su documentación.

Muchos equipos usan ambas: Postman para construir y verificar las comprobaciones de la API, JMeter para dar volumen real a los flujos críticos.

FAQ

¿Puede Postman sustituir a JMeter en pruebas de carga? Para comprobaciones pequeñas de APIs HTTP sí, porque la colección que ya tienes es la prueba. Con alta concurrencia, otros protocolos o ejecuciones largas, los límites documentados de las ejecuciones locales y el precio por uso de las ejecuciones en la nube hacen de JMeter la base más segura.

¿Puede Postman ejecutar un archivo .jmx de JMeter? No hemos encontrado nada en su documentación que importe un plan de prueba de JMeter. Las pruebas de rendimiento de Postman se construyen a partir de colecciones, así que habría que rehacer un archivo .jmx.

¿Es gratis JMeter? Sí. La versión actual en la página de descargas es la 5.6.3, que requiere Java 8 o posterior (comprobado el 13 de octubre de 2026). Pagas las máquinas que generan la carga, o un servicio en la nube que ejecute tus planes.

Lecturas relacionadas

k6 vs Locust: ¿scripts JavaScript o usuarios Python?

Tue, 13 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

k6 y Locust son dos herramientas de código abierto que mantienen una prueba de carga como código en tu repositorio, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige Locust si tu equipo escribe Python y quiere la lógica de la prueba en Python puro. Elige k6 si escribes JavaScript, quieres umbrales de éxito integrados o necesitas una prueba que mantenga una tasa de llegada.

Los datos de esta comparación de k6 y Locust proceden de la documentación y del repositorio de cada proyecto, comprobados el 13 de octubre de 2026.

	k6	Locust
Licencia	AGPL-3.0 (repositorio)	MIT (repositorio)
Ejecución	Un binario de Go con un motor JavaScript integrado (versión v2.3.0)	Python 3.11 o posterior (versión 2.46.7)
Scripts de prueba	JavaScript, o TypeScript al que se le quitan los tipos	Clases de Python en un locustfile
Protocolos integrados	HTTP/1.1, HTTP/2, WebSockets, gRPC	HTTP y HTTPS
Modelo de carga	Seis ejecutores, dos de ellos arrival-rate (modelo abierto)	Un grupo de usuarios que esperan cada uno un tiempo (modelo cerrado)
Éxito o fallo	Umbrales, que pueden abortar una ejecución antes	Código de salida 1 si fallan peticiones; otros límites mediante un listener
Pruebas de navegador	Módulo de navegador integrado	Usuarios de navegador mediante el proyecto aparte locust-plugins
Escalado	k6-operator en Kubernetes, o Grafana Cloud k6	Master y workers, un operador de Kubernetes o Azure Load Testing

¿Cuál es la diferencia entre k6 y Locust?

La diferencia principal es el lenguaje en el que escribes las pruebas. k6 ejecuta JavaScript dentro de un programa de Go compilado, mientras que Locust ejecuta tu código Python y se apoya en gevent para muchos usuarios concurrentes.

k6 se instala como paquete o binario independiente, sin otro entorno de ejecución. También ejecuta archivos .ts, aunque su compatibilidad con TypeScript quita los tipos sin comprobarlos. Locust se instala con pip install locust, y su página What is Locust dice que las pruebas son Python corriente que guardas en control de versiones como cualquier otro código (comprobado el 13 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

Las dos expresan la prueba como un programa corto. Aquí va una prueba con 50 usuarios durante cinco minutos que falla si el percentil 95 supera los 500 ms o si más del 1 % de las peticiones fallan.

En k6 los objetivos forman parte del script, como umbrales:

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

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

En Locust el usuario es una clase, y los mismos objetivos van en un listener, siguiendo el patrón de la documentación del modo headless:

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

Se lanzan con k6 run script.js y locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (comprobado el 13 de octubre de 2026).

¿Cómo modelan la carga k6 y Locust?

k6 admite los dos modelos de carga, mientras que Locust describe la carga como un número fijo de usuarios. En k6 eliges el modelo con el ejecutor, y en Locust con el número de usuarios y el tiempo de espera.

k6 tiene seis ejecutores. Cuatro son cerrados: un usuario virtual empieza su siguiente iteración solo cuando termina la anterior. Los dos ejecutores arrival-rate siguen el modelo abierto, en el que las iteraciones empiezan con independencia de lo que tarden las anteriores. La guía del locustfile dice que el tiempo de espera solo puede limitar el rendimiento y no puede lanzar usuarios nuevos para alcanzar una tasa objetivo (comprobado el 13 de octubre de 2026).

Si tu objetivo es «300 peticiones llegan cada segundo, sea cual sea el tiempo de respuesta», k6 puede expresarlo directamente. Nuestra guía sobre el modelo de carga abierto y cerrado explica cuándo encaja cada uno.

¿Cómo deciden k6 y Locust si una prueba ha pasado?

k6 tiene los criterios de éxito como función central, y Locust deja la mayor parte a tu código. Un umbral de k6 incumplido termina la ejecución con un código de salida distinto de cero, y abortOnFail detiene la prueba en cuanto falla.

Locust termina con código 1 si alguna petición ha fallado. Para límites sobre la tasa de fallos, la media o el percentil 95, su documentación muestra un listener como el de arriba, que fija el código de salida por su cuenta (comprobado el 13 de octubre de 2026). Nuestra guía sobre los criterios de aprobación de una prueba de carga ayuda a elegir los límites.

¿Qué protocolos cubre cada herramienta?

k6 incluye cuatro protocolos y un módulo de navegador; Locust incluye HTTP y HTTPS y te deja envolver cualquier cliente de Python para el resto.

k6 enumera HTTP/1.1, HTTP/2, WebSockets y gRPC como protocolos integrados, con más mediante extensiones xk6, y un módulo de navegador que maneja un navegador basado en Chromium. La página de Locust sobre otros sistemas dice que solo trae soporte integrado para HTTP/HTTPS, pero que se puede extender para probar casi cualquier sistema, envolviendo una biblioteca de protocolo e informando de cada llamada como una petición. La biblioteca debe cooperar con gevent (comprobado el 13 de octubre de 2026).

¿Cómo se ejecuta una prueba mayor de lo que genera una máquina?

Locust escala con un master y workers, y k6 con un operador de Kubernetes o un servicio alojado. Ambos pueden repartir una prueba entre muchas máquinas.

La documentación del modo distribuido de Locust dice que un proceso puede hacer más de mil peticiones por segundo con un plan de prueba sencillo, así que las pruebas mayores usan un worker por núcleo de procesador en tantas máquinas como haga falta. El k6-operator reparte una prueba entre varias instancias de k6 en un clúster de Kubernetes, y Grafana Cloud k6 es la vía alojada (comprobado el 13 de octubre de 2026).

Hay una tercera vía para los scripts de k6. LoadFocus, que publica este sitio, ejecuta scripts de k6 desde 25 regiones en la nube, con los usuarios y la duración tomados de los ajustes de la prueba. Su validador de scripts avisa de que los escenarios arrival-rate se ejecutan allí con un número fijo de usuarios, de modo que un script de modelo abierto no mantiene su tasa de llegada en LoadFocus. LoadFocus no ejecuta Locust: solo ejecuta scripts de k6 y planes de prueba de JMeter.

¿Qué informes se obtienen?

k6 imprime un resumen al final de la prueba y puede exportar un informe HTML desde su panel web. Locust muestra gráficos en vivo en su interfaz web y escribe archivos si se lo pides.

El resumen de fin de prueba de k6 sale por la terminal, y su panel web exporta un informe HTML autónomo cuando defines K6_WEB_DASHBOARD_EXPORT. Locust ofrece una interfaz web en el puerto 8089 con gráficos en vivo, y su referencia de configuración lista las salidas --csv, --html y --json (comprobado el 13 de octubre de 2026).

¿Cuál deberías elegir?

Locust encaja con equipos de Python, y k6 con equipos que quieren umbrales integrados y un modelo de carga abierto. Los protocolos y el escalado deciden la mayoría de los demás casos.

Elige Locust en lugar de k6 si tu equipo escribe Python y quiere bucles, ramas, datos generados y su propio cliente de API en Python puro, si quieres reutilizar bibliotecas de Python para un protocolo, o si quieres una interfaz web con gráficos en vivo para explorar un sistema. Elige k6 en lugar de Locust si tu equipo escribe JavaScript o TypeScript, si los umbrales deben hacer fallar una compilación de CI y detener pronto una mala ejecución, si necesitas una tasa de llegada constante, o si quieres gRPC y pruebas de navegador en la misma herramienta.

Para una visión más amplia, consulta nuestra reseña de las pruebas de carga con Locust.

FAQ

¿Es Locust más rápido que k6? No lo hemos medido nosotros, así que no nombramos un ganador. La prueba justa es el mismo escenario con ambas herramientas en tu propio hardware.

¿Puede Locust ejecutar scripts de k6? No según la documentación de Locust, que describe las pruebas como código Python en un locustfile. Un script de k6 es JavaScript, así que hay que reescribirlo como una clase de usuario de Python, y los umbrales pasan a ser un listener.

¿Puede LoadFocus ejecutar pruebas de Locust? No. LoadFocus ejecuta scripts de k6 y planes de prueba de JMeter. Para escalar una prueba de Locust, usa su modo master y workers, el operador de Kubernetes o Azure Load Testing.

Lecturas relacionadas

Coordinated omission: qué es y cómo evitarla

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

La coordinated omission es un error de medición: un generador de carga espera cada respuesta lenta antes de enviar su siguiente petición, así que envía menos justo cuando el sistema va lento y registra muy pocos de los peores momentos. Los percentiles que lees después parecen mejores que lo que vivieron los usuarios. Se evita enviando las peticiones según una programación que ignora los tiempos de respuesta y midiendo cada petición desde el momento en que debía salir.

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

Herramienta	Qué ofrece	Qué revisar
wrk2	Una tasa constante (`-R`), latencia medida desde el envío previsto	`--u_latency` añade la vista sin corregir
HdrHistogram	Dos métodos que rellenan las muestras que faltan	Aplicar solo uno, nunca los dos
k6	Los ejecutores arrival-rate	El contador `dropped_iterations`
Gatling	Pasos de `injectOpen` como `constantUsersPerSec`	Que los pasos estén dentro de `injectOpen`
Locust	`constant_throughput` marca el ritmo de cada usuario	La tasa lograda frente al objetivo
JMeter	Open Model Thread Group (5.5 o posterior, experimental)	Un Thread Group normal es un pool cerrado

¿Qué es la coordinated omission?

Es el error que aparece cuando el lado que mide deja de tomar muestras porque el sistema va lento, de modo que las muestras que faltan son justo las lentas. Perder muestras al azar apenas mueve un percentil; perderlas al compás de una ralentización los distorsiona todos.

El nombre viene de Gil Tene, cuyo mensaje de 2013 en una lista de correo traza esa misma línea. Es el autor original de HdrHistogram, wrk2 está en su cuenta de GitHub y la documentación de ambos proyectos explica el efecto (comprobado el 9 de octubre de 2026). La documentación de k6 usa el término para un modelo de carga cerrado que frena su propia carga, una causa frecuente. Nuestro artículo sobre el modelo de carga abierto vs cerrado trata esa elección; este se centra en la medición.

¿Cómo acaba una prueba de carga ocultando las respuestas lentas?

Un generador en bucle cerrado envía la siguiente petición por una conexión solo cuando llega la respuesta anterior. Si una respuesta tarda un segundo, esa conexión no envía nada durante un segundo, y las peticiones que habría enviado nunca obtienen un tiempo de respuesta.

El README de wrk2 lo dice del modelo de wrk, que mide cada petición desde el primer byte enviado hasta la respuesta completa: como una conexión solo envía tras una respuesta, el generador se coordina con el servidor y evita medir durante los periodos de alta latencia (comprobado el 9 de octubre de 2026).

El README de HdrHistogram plantea un experimento mental. Un sistema muestreado cada 10 ms responde en 1 ms durante 100 segundos y luego se queda parado 100 segundos, lo que deja una única muestra de 100 segundos. El histograma en bruto sitúa cerca del 99,99 % de los resultados en 1 ms o menos; corregido por las muestras bloqueadas, solo la mitad aproximadamente.

¿Cómo saber si tus resultados tienen coordinated omission?

Compara la tasa enviada con la prevista. Si la tasa de peticiones bajó mientras subían los tiempos de respuesta, el generador aflojó y el periodo lento está infrarrepresentado.

La carga se definió en usuarios o conexiones, sin tasa. Cualquier bucle cerrado puede provocar el error.
La tasa de peticiones cae donde suben los tiempos de respuesta. Un bache en la tasa durante un pico significa que hubo peticiones que nunca salieron.
El máximo es muchísimo mayor que el percentil 99. Unas pocas muestras enormes entre miles de rápidas son el ejemplo anterior en miniatura. Lee toda la distribución de tiempos de respuesta, sabiendo que solo cuenta las peticiones enviadas.
Al generador de carga le faltó CPU. LoadFocus documenta que un motor cerca del 100 % de CPU no puede enviar a la tasa configurada, y sus resultados muestran un aviso de saturación del generador de carga cuando algún motor alcanzó o superó el 80 % de CPU en su pico.

¿Cómo evita wrk2 la coordinated omission?

Envía a tasa constante y mide cada petición desde el momento en que el plan decía que debía salir. Una petición que sale tarde porque su conexión estaba ocupada carga con la espera.

wrk2 añade a wrk un argumento de tasa (-R, peticiones por segundo en total) y registra las latencias en un HdrHistogram. --u_latency añade al informe el histograma sin corregir, marcado como CO, como en el ejemplo del propio README:

wrk -t2 -c100 -d30s -R2000 --u_latency http://127.0.0.1:80/index.html

En el segundo ejemplo del README, una pausa del servidor de 1,4 segundos durante una prueba de 30 segundos hizo que el percentil 99 corregido fuera 200 veces el no corregido. El README también califica el proyecto de experimental y advierte que las pruebas de menos de 10 a 20 segundos pueden no ser útiles (comprobado el 9 de octubre de 2026). Nuestra comparativa de herramientas de benchmark HTTP compara wrk2 con hey, oha y otras.

¿Cómo corrige HdrHistogram las latencias registradas?

Si conoces el intervalo al que debían salir las peticiones, añade las muestras que una respuesta larga bloqueó. La corrección se aplica al registrar o después, sobre una copia.

recordValueWithExpectedInterval registra un valor y, si supera el intervalo, añade valores que bajan en pasos de ese intervalo. copyCorrectedForCoordinatedOmission devuelve una copia corregida de un histograma terminado. El JavaDoc describe los dos métodos como mutuamente excluyentes (comprobado el 9 de octubre de 2026).

// intervalo previsto: 10 ms, valores en microsegundos
Histogram h = new Histogram(3);
h.recordValueWithExpectedInterval(latencyUs, 10_000);

// o, tras la prueba, sobre un histograma en bruto:
Histogram fixed = raw.copyCorrectedForCoordinatedOmission(10_000);

La corrección vale lo que vale el intervalo que le pasas. Encaja, por tanto, con un generador que debía enviar a un ritmo constante.

¿Cómo lo resuelven k6, Gatling, Locust y JMeter?

k6, Gatling y JMeter pueden iniciar trabajo según una programación que no espera respuestas. Locust marca el ritmo de cada usuario, pero no puede lanzar usuarios extra para mantener una tasa.

k6. En los ejecutores arrival-rate, las iteraciones empiezan con independencia de la respuesta del sistema mientras haya un usuario virtual libre. Cuando no lo hay, k6 se salta la iteración y la cuenta en dropped_iterations, lo que, avanzada la prueba, puede indicar que el sistema se degrada (comprobado el 9 de octubre de 2026). Una iteración descartada no tiene tiempo de respuesta, así que lee ese contador junto a los percentiles. En LoadFocus, los escenarios de tasa de llegada de los scripts de k6 se ejecutan con un número fijo de usuarios, es decir, como modelo cerrado. Ejecuta k6 por tu cuenta cuando la tasa de llegada sea lo que quieres probar.

Gatling. Pasos como constantUsersPerSec dentro de injectOpen inician nuevos usuarios virtuales a una tasa fija, hayan terminado o no los anteriores (comprobado el 9 de octubre de 2026).

Locust. constant_throughput ajusta la espera de cada usuario para que ejecute una tarea como mucho un número dado de veces por segundo. La documentación dice que el tiempo de espera solo puede limitar la tasa y no lanza usuarios nuevos, y la referencia de la API añade que tras una tarea que se pasa de su intervalo no hay espera. Una respuesta lenta retrasa igualmente a ese usuario (comprobado el 9 de octubre de 2026).

JMeter. Un Thread Group es un pool de hilos que repiten el plan en bucle, es decir, un bucle cerrado. JMeter 5.5 añadió el Open Model Thread Group, experimental, que sigue una programación como rate(1/sec) random_arrivals(2 min) y, según las notas de versión, crea hilos según haga falta (comprobado el 9 de octubre de 2026).

¿Elimina un modelo de carga abierto la coordinated omission?

Elimina la causa principal, un generador que espera antes de enviar. Quedan dos huecos: un generador sin usuarios o CPU suficientes se queda igualmente atrás respecto a su programación, y cada usuario de un recorrido de varios pasos sigue esperando sus propias respuestas.

El primero se ve como iteraciones descartadas o como un motor saturado; en ambos casos, repite la prueba con más margen. El segundo viene con la mayoría de las pruebas HTTP: el README de wrk2 señala que enviar sin esperar solo sirve con protocolos no bloqueantes o con una petición por conexión, y por eso wrk2 corrige la medición del tiempo.

FAQ

¿Quién le puso nombre a la coordinated omission? Gil Tene, el autor original de HdrHistogram, cuyo fork wrk2 de wrk está pensado para evitarla. Su mensaje de 2013 en la lista de correo mechanical-sympathy la describe como un problema al que él llama así.

¿Es la coordinated omission lo mismo que un modelo de carga cerrado? Están relacionados. Un modelo cerrado es una causa frecuente, porque cada usuario virtual espera su respuesta antes de volver a enviar, y el README de wrk2 también encuentra el efecto en código de monitorización.

¿Hay que corregir todos los histogramas de latencia? Solo si conoces el intervalo al que estaban previstas las peticiones, porque HdrHistogram lo necesita para rellenar las muestras que faltan. Aplica a un conjunto de datos uno de sus dos métodos de corrección, nunca los dos.

Lecturas relacionadas

Pruebas de carga con Gatling: la herramienta JVM a fondo

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Gatling es una herramienta gratuita de pruebas de carga con licencia Apache 2.0, en la que cada prueba es una simulación escrita como código que se ejecuta en la JVM y deja un informe HTML al terminar. Las pruebas de carga con Gatling encajan con equipos de desarrollo que quieren las pruebas en el repositorio, modelos de carga abiertos o cerrados y aserciones que hagan fallar el build. A los equipos que quieren un editor gráfico de pruebas o muchos protocolos les sirve mejor JMeter, y a los que quieren un único binario sin JVM, k6.

No hemos ejecutado Gatling para este análisis. Los datos proceden de la documentación, el repositorio y las páginas de versiones de Gatling, comprobados el 9 de octubre de 2026, y las valoraciones son nuestras.

Tema	Gatling
Licencia	Apache 2.0, salvo los plugins de gRPC, MQTT y GraphQL
Entorno	JVM, OpenJDK LTS de 64 bits del 11 al 25
Versión actual	3.16.0 (29 de septiembre de 2026)
Pruebas escritas en	Java, Kotlin, Scala, JavaScript, TypeScript
Protocolos integrados	HTTP/1.1, HTTP/2, WebSocket, SSE, JMS
Resultados	Informe HTML estático por ejecución
Build y CI	Plugins para Maven, Gradle, sbt y npm
Escalado	Gatling Enterprise (comercial)

¿Quién desarrolla Gatling y sigue manteniéndose?

Gatling Corp, una empresa francesa, desarrolla Gatling y tiene sus derechos de autor. Se mantiene de forma activa, con tres versiones para la JVM en lo que va de 2026.

La página de licencias atribuye los derechos de autor a Gatling Corp. Maven Central recoge la 3.15.0 en febrero, la 3.15.1 en mayo y la 3.16.0 el 29 de septiembre de 2026, y el SDK de JavaScript llegó a la 3.16.1 el 6 de octubre. Las notas de la versión 3.16 añaden GraphQL y colas compartidas entre usuarios virtuales. El README presenta el repositorio como la Community Edition, de uso libre incluso comercial (comprobado el 9 de octubre de 2026).

¿Qué necesitas para ejecutar Gatling?

Una JVM de 64 bits para Java, Kotlin o Scala, o Node.js para JavaScript y TypeScript. En ambos casos, la simulación en sí se ejecuta en una JVM.

La página de instalación admite las versiones LTS de OpenJDK del 11 al 25 y excluye las JVM de 32 bits y OpenJ9. La CLI de JavaScript requiere Node.js 24 o posterior y descarga un paquete de ejecución de Gatling y, según el README de gatling-js, GraalVM (comprobado el 9 de octubre de 2026).

¿Cómo se estructura una simulación de Gatling?

Una simulación define escenarios, asigna a cada uno un perfil de inyección y les añade una configuración de protocolo, todo registrado en una sola llamada a setUp.

En la referencia de simulaciones, un escenario encadena peticiones con pausas, bucles y condiciones. Esta simulación en Java guarda el id de un producto obtenido en una búsqueda, hace una pausa de uno a tres segundos y abre el producto, mientras las llegadas suben a 20 usuarios por segundo y se mantienen diez minutos:

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Los imports se omiten, y #{id} lee el valor guardado mediante el Expression Language de Gatling. Gatling vs k6 muestra una simulación en JavaScript.

¿Conviene inyectar usuarios con un modelo abierto o cerrado?

Abierto, para la mayoría de sitios web y API, donde siguen llegando usuarios nuevos por mucho que se ralentice el sistema. El cerrado encaja con sistemas que limitan la concurrencia, como una cola de venta de entradas.

La referencia de inyección divide la API: injectOpen recibe tasas de llegada como rampUsersPerSec, e injectClosed, objetivos de concurrencia como constantConcurrentUsers. La página sobre modelos de carga dice que la mayoría de los sitios web se comportan como sistemas abiertos y que un perfil no puede mezclar ambos (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica cómo elegir.

¿Cómo funcionan los checks, las aserciones y el informe?

Los checks verifican cada respuesta y pueden guardar valores de ella, mientras que las aserciones juzgan la ejecución completa cuando termina. Después, cada ejecución genera un informe HTML.

Sin un check de estado explícito, Gatling comprueba que cada respuesta HTTP sea 2XX o 304. Las aserciones evalúan tiempos de respuesta, número de peticiones o peticiones por segundo, de forma global o por petición, y una sola aserción fallida hace fallar la simulación. El informe HTML muestra rangos de tiempo de respuesta y percentiles, usuarios iniciados por segundo, usuarios concurrentes y peticiones por segundo; sus percentiles a lo largo del tiempo solo cuentan peticiones correctas (comprobado el 9 de octubre de 2026).

¿Cómo encaja Gatling en el build y la CI?

A través de su plugin para Maven, Gradle, sbt o npm, que funciona en cualquier sistema de CI. Una aserción fallida hace fallar el build.

El plugin de Maven vincula gatling:test a la fase integration-test, así que mvn verify lo ejecuta, y con CI=true deja de preguntar qué simulación lanzar (la ejecución falla entonces si el proyecto tiene más de una simulación y no se indica ninguna). El plugin de Gradle usa gatlingRun, y el plugin de sbt solo admite simulaciones en Scala. Las integraciones de CI ya hechas de Gatling, como su GitHub Action, lanzan ejecuciones en Gatling Enterprise (comprobado el 9 de octubre de 2026). Nuestra guía de GitHub Actions cubre la parte del workflow.

¿Qué protocolos admite Gatling?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS vienen sin límites. gRPC, MQTT y GraphQL son plugins aparte, limitados a 5 usuarios y 5 minutos fuera de Gatling Enterprise.

El README incluye los cinco primeros bajo Apache 2.0. Las páginas de configuración de gRPC, MQTT y GraphQL ponen cada plugin bajo la Gatling Enterprise Component License: sin límites en Gatling Enterprise, mientras que una prueba con la Community Edition se detiene a los 5 usuarios o los 5 minutos. Esa licencia concede un uso gratuito durante un año como máximo, solo para probar internamente tus propias aplicaciones web; termina en cuanto se alcanza un límite, y Gatling puede cambiar los límites. GraphQL requiere la 3.16.0 o posterior. Sus notas de versión y el README dicen que el SDK de JavaScript todavía no lo soporta, aunque la página de configuración ya muestra un paquete npm, así que compruébalo antes de planificar una prueba de GraphQL en JavaScript (comprobado el 9 de octubre de 2026). Nuestra guía sobre cómo hacer una prueba de carga a una API GraphQL sortea el límite con peticiones HTTP normales.

¿Qué añade Gatling Enterprise?

Gatling Enterprise es la edición comercial sobre el mismo motor. Genera carga desde infraestructura gestionada o privada, algo que la edición gratuita no hace.

Según el README, Enterprise ejecuta las pruebas en generadores de carga gestionados o en tus propias cuentas de AWS, Azure, GCP o Kubernetes, y añade paneles en directo, tendencias, equipos con SSO e integraciones de CI/CD. Las preguntas frecuentes indican que la Community Edition no admite pruebas distribuidas y que las simulaciones pasan a Enterprise sin cambios (comprobado el 9 de octubre de 2026).

LoadFocus, que publica este sitio, no ejecuta simulaciones de Gatling. Ejecuta planes de prueba de JMeter y scripts de k6 desde 25 regiones cloud, así que para Gatling el camino hacia más máquinas es Gatling Enterprise.

¿Qué hace bien Gatling y dónde están sus límites?

Destaca en pruebas como código revisable, en modelos de carga y en informes sin configuración. Se queda corto en protocolos más allá de la web y la mensajería, y al escalar gratis más allá de una máquina.

El README destaca su motor: no bloqueante, construido sobre Netty, donde cada usuario virtual es un mensaje ligero. Límites que la propia documentación reconoce (comprobado el 9 de octubre de 2026):

Gatling no es un navegador: según la página del protocolo HTTP, no ejecuta JavaScript.
El SDK de JavaScript no tiene JMS y no puede usar librerías de npm que necesiten binarios nativos o API propias de Node.js.
La caché HTTP está activada por defecto, lo que puede reducir el número de peticiones.
El formato de simulation.log no está documentado y puede cambiar en cualquier momento.

¿Cuándo elegir k6, JMeter o Locust en lugar de Gatling?

Elige otra herramienta cuando su lenguaje, sus protocolos o su forma gratuita de escalar encajen mejor con tu equipo.

Nuestro repaso de herramientas de pruebas de carga open source sitúa Gatling junto a otras cinco.

Elige k6 si quieres en la CI un único binario sin JVM, thresholds que puedan detener pronto una ejecución fallida o gRPC entre sus protocolos integrados (comprobado el 9 de octubre de 2026). Gatling vs k6 compara las dos.

Elige JMeter si tus testers crean las pruebas en una interfaz gráfica, o si necesitas JDBC, LDAP o FTP desde su núcleo (comprobado el 9 de octubre de 2026). LoadFocus ejecuta tus planes de prueba de JMeter desde 25 regiones cloud, y Gatling vs JMeter profundiza más.

Elige Locust si tu equipo escribe Python y quiere un modo distribuido en la herramienta gratuita (comprobado el 9 de octubre de 2026). Nuestro análisis de Locust lo cubre.

FAQ

¿Gatling es gratuito para uso comercial? Sí. La Community Edition tiene licencia Apache 2.0. Los plugins de gRPC, MQTT y GraphQL tienen su propia licencia y se detienen a los 5 usuarios y 5 minutos fuera de Gatling Enterprise.

¿Hace falta Java para usar Gatling? Para Java, Kotlin o Scala, sí: un OpenJDK LTS de 64 bits del 11 al 25. El SDK de JavaScript necesita Node.js 24 o posterior, y su CLI descarga por sí misma el entorno JVM.

¿Puede LoadFocus ejecutar pruebas de Gatling? No. LoadFocus ejecuta planes de prueba de JMeter y scripts de k6. Para repartir una simulación de Gatling entre varias máquinas, usa Gatling Enterprise.

Lecturas relacionadas

Gatling vs JMeter: ¿pruebas como código o un plan en GUI?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Gatling y Apache JMeter son dos herramientas de pruebas de carga gratuitas y open source que funcionan sobre la JVM, y la elección depende sobre todo de cómo quiere construir las pruebas tu equipo. Elige Gatling si quieres las pruebas como código en Java, Kotlin, Scala, JavaScript o TypeScript, perfiles de inyección abiertos y un informe HTML después de cada ejecución. Elige JMeter si necesitas protocolos como JDBC, LDAP, FTP o correo sin añadir nada, prefieres montar las pruebas en una interfaz gráfica o ya tienes planes de prueba .jmx.

Los datos de esta comparativa Gatling vs JMeter vienen de la documentación y el repositorio de cada proyecto, comprobados el 9 de octubre de 2026.

	Gatling	Apache JMeter
Licencia	Apache 2.0; gRPC, MQTT y GraphQL con una licencia de componentes aparte (repositorio)	Apache 2.0 (repositorio)
Entorno de ejecución	JVM, OpenJDK LTS 11 a 25 (versión 3.16.0)	JVM, Java 8 o posterior (versión 5.6.3)
Pruebas escritas como	Código en Java, Kotlin, Scala, JavaScript o TypeScript	Planes de prueba montados en una interfaz gráfica y guardados en XML (`.jmx`)
Protocolos integrados	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, correo, TCP, comandos de shell, objetos Java
Grabador	Proxy HTTP o conversor de archivos HAR	HTTP(S) Test Script Recorder (proxy)
Modelo de carga	Perfiles de inyección abiertos o cerrados	Thread Groups; un Open Model Thread Group experimental
Escalado	Una máquina; la ejecución distribuida requiere Gatling Enterprise	Modo remoto integrado, un cliente que controla varios servidores
CI y ejecución sin interfaz	Plugins de Maven, Gradle, sbt y npm; una assertion fallida hace fallar la ejecución	Modo CLI (`jmeter -n`); plugins de terceros para Maven, Gradle y Jenkins
Informes	Informe HTML después de cada ejecución	Panel HTML; resultados en directo con un Backend Listener

¿Cuál es la diferencia entre Gatling y JMeter?

En Gatling una prueba es un programa dentro de un proyecto de build. En JMeter una prueba es un árbol de elementos que montas en una interfaz gráfica de escritorio y guardas como archivo XML, y de ahí salen casi todas las demás diferencias.

El README de Gatling llama simulaciones a las pruebas y las guarda en tu repositorio como el código de la aplicación, y se ejecutan con un plugin de Maven, Gradle, sbt o npm. El SDK de JavaScript y TypeScript se instala con npm y descarga su propio entorno GraalVM.

Un plan de JMeter tiene un Thread Group para los usuarios, samplers para las peticiones y assertions y listeners para los resultados. JMeter 5.6.3, la versión actual en la página de descarga, requiere Java 8 o posterior. El README de la rama de desarrollo de JMeter ya exige Java 17 (comprobado el 10 de octubre de 2026). Por dentro, JMeter ejecuta cada usuario virtual como un hilo de Java, mientras que el README de Gatling describe los usuarios virtuales como mensajes ligeros sobre un motor no bloqueante construido con Netty.

¿Cómo se escribe una prueba en cada herramienta?

En Gatling escribes una clase de simulación que define un escenario, un perfil de inyección y assertions. En JMeter añades un Thread Group y samplers en la interfaz gráfica, guardas el plan y luego lo ejecutas desde la línea de comandos.

Una simulación en Java basada en el tutorial de la primera simulación de Gatling: los usuarios nuevos llegan primero a razón de uno por segundo, suben a diez por segundo en un minuto y se mantienen así durante cinco minutos. La ejecución falla si el percentil 95 supera los 500 ms o si falla más del 1 % de las peticiones:

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Ejecútala con ./mvnw gatling:test; una simulación en JavaScript o TypeScript se ejecuta con npx gatling run.

En JMeter la misma prueba es un Thread Group con un sampler HTTP Request, y una Duration Assertion puede marcar como fallida cada respuesta lenta. La guía de inicio monta el plan en modo GUI y lo ejecuta en modo CLI, y -e -o añade el informe HTML:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Las dos herramientas pueden grabar un primer borrador desde el navegador. El Recorder de Gatling funciona como proxy HTTP o convierte un archivo HAR en una simulación, y el HTTP(S) Test Script Recorder de JMeter captura el tráfico del navegador en un plan (comprobado el 9 de octubre de 2026). La documentación de Gatling ya presenta este Recorder como legacy, y el más reciente Gatling Studio exige una cuenta de Enterprise para iniciar sesión (comprobado el 10 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

JMeter cubre más protocolos de serie. Gatling trae los principales protocolos web más JMS y deja casi todo lo demás a componentes aparte o a plugins de la comunidad.

El README de JMeter recoge todos los protocolos de la tabla anterior, correo incluido. JDBC y JMS necesitan los JAR del driver de tu base de datos o de tu proveedor JMS, y el Plugins Manager instala plugins de la comunidad desde la propia interfaz gráfica.

Según el README de Gatling, gRPC, MQTT y GraphQL son componentes aparte con la Gatling Enterprise Component License, limitados sin Enterprise a cinco usuarios simultáneos y pruebas de cinco minutos. Kafka, AMQP, SFTP, FTP y JDBC llegan con plugins de terceros para Gatling 3.13 que Gatling no mantiene (comprobado el 9 de octubre de 2026).

¿Cómo modelan la carga Gatling y JMeter?

Gatling te hace elegir entre un modelo abierto y uno cerrado en el propio script. El Thread Group clásico de JMeter es un grupo cerrado de usuarios, y la carga basada en llegadas necesita el más reciente Open Model Thread Group.

En Gatling, injectOpen recibe tasas de llegada como constantUsersPerSec y rampUsersPerSec, e injectClosed objetivos de concurrencia como constantConcurrentUsers. JMeter 5.5 añadió el Open Model Thread Group, que la referencia sigue marcando como experimental (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica por qué importa esa elección.

¿Cómo se reparte una prueba entre varias máquinas?

JMeter trae un modo distribuido integrado. La edición open source de Gatling genera carga desde una sola máquina, y su documentación pide una cuenta de Gatling Enterprise para la ejecución distribuida.

El modo de pruebas remotas de JMeter permite que un cliente controle cualquier número de servidores. Cada servidor ejecuta el plan completo, así que 1.000 hilos en seis servidores son 6.000 hilos. Todos los nodos deberían usar la misma versión de JMeter y de Java, RMI necesita un keystore salvo que desactives SSL, y los archivos de datos hay que copiarlos a cada servidor.

Hay una tercera vía para los planes de prueba de JMeter. LoadFocus, que publica este sitio, ejecuta tus planes de prueba de JMeter sin cambios desde 25 regiones cloud, sin servidores remotos que configurar. LoadFocus no ejecuta simulaciones de Gatling.

¿Cómo encajan en CI y qué informes obtienes?

Las dos se ejecutan sin interfaz. Las assertions de Gatling pueden hacer fallar el build directamente, mientras que las de JMeter marcan muestras sueltas y la integración con CI llega con bibliotecas de terceros.

Las assertions de Gatling se comprueban al terminar la ejecución, y una sola assertion fallida hace fallar la simulación y la tarea de build. El informe HTML muestra percentiles del tiempo de respuesta, usuarios iniciados por segundo, usuarios simultáneos y peticiones por segundo a lo largo del tiempo.

El modo CLI de JMeter no tiene criterios de aprobación, así que un objetivo incumplido solo hace fallar el build mediante las bibliotecas para Maven, Gradle y Jenkins que cita su README, o con una comprobación propia. El panel de JMeter añade una tabla APDEX, una tabla de estadísticas con tres percentiles configurables y resúmenes de errores, y un Backend Listener envía resultados en directo a InfluxDB o Graphite.

¿Cuál deberías elegir?

Elige Gatling si tu equipo escribe Java, Kotlin, Scala o TypeScript y quiere revisar las pruebas de carga como el resto de su código. Elige JMeter en su lugar si necesitas protocolos más allá de la web, si tus testers prefieren una interfaz gráfica o si ya tienes planes .jmx.

Gatling encaja con equipos que describen el tráfico como tasas de llegada y quieren las reglas de aprobado o fallo junto al escenario, con un informe legible sin configuración extra.

JMeter es la mejor opción para probar JDBC, LDAP, FTP o correo, para testers que refinan visualmente un flujo grabado y para ejecuciones distribuidas en tus propios servidores sin licencia comercial. Una empresa que ya usa JMeter conserva además sus planes, sus plugins y su experiencia.

FAQ

¿Gatling es más rápido que JMeter? No lo hemos medido nosotros, así que no vamos a nombrar un ganador. La comparación justa es el mismo escenario con las dos herramientas en tu propio hardware.

¿Gatling puede ejecutar archivos .jmx de JMeter? No directamente. Gatling ejecuta simulaciones escritas con sus SDK, así que un plan de JMeter hay que reescribirlo. El README de Gatling menciona extensiones de IA que convierten planes de prueba de JMeter, y requieren un token de API de Gatling Enterprise.

¿LoadFocus puede ejecutar pruebas de Gatling? No. LoadFocus ejecuta planes de prueba de JMeter y scripts de k6. Para repartir una simulación de Gatling entre varias máquinas, usa Gatling Enterprise.

Lecturas relacionadas

Gatling vs k6: ¿simulaciones en la JVM o un binario Go?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Gatling y k6 son herramientas open source que guardan las pruebas de carga como código en tu repositorio, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige Gatling si tu equipo trabaja en Java, Kotlin o Scala, o si quieres un informe HTML después de cada ejecución sin configurar nada. Elige k6 si quieres un único binario de Go sin JVM, gRPC y pruebas de navegador de serie, y umbrales capaces de detener antes de tiempo una ejecución que falla.

Los datos de esta comparación Gatling vs k6 salen de la documentación y del repositorio de cada proyecto, comprobados el 9 de octubre de 2026.

	Gatling	k6
Licencia	Apache 2.0; gRPC, MQTT y GraphQL con una licencia de componentes aparte (repositorio)	AGPL-3.0 (repositorio)
Entorno de ejecución	JVM; el SDK de Java requiere OpenJDK LTS 11 a 25 (versión 3.16.0)	Un binario de Go con un motor JavaScript integrado (versión v2.3.0)
Scripts de prueba	Java, Kotlin, Scala, JavaScript o TypeScript	JavaScript, o TypeScript sin comprobación de tipos
Protocolos principales	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP/1.1, HTTP/2, WebSockets, gRPC
Modelo de carga	Perfiles de inyección abiertos o cerrados	Seis executors, dos de ellos con tasa de llegada (modelo abierto)
Criterios de éxito	Assertions, comprobadas al terminar	Thresholds, que también pueden abortar una ejecución
Informes	Informe HTML después de cada ejecución	Resumen al final de la prueba; panel web con exportación HTML
Pruebas de navegador	Nada integrado; el Recorder convierte el tráfico del navegador en código	Módulo de navegador integrado (controla un navegador basado en Chromium)
Escalado	Gatling Enterprise	k6-operator en Kubernetes, o Grafana Cloud k6

¿Cuál es la diferencia entre Gatling y k6?

La mayor diferencia es el entorno de ejecución. Gatling corre en la JVM y escribes las pruebas con uno de sus SDK, mientras que k6 es un único programa compilado en Go que ejecuta JavaScript.

El README de Gatling menciona un SDK de Java para Java, Kotlin y Scala, que se ejecuta con un plugin de Maven, Gradle o sbt. Su SDK de JavaScript y TypeScript se instala con npm, y su herramienta de línea de comandos descarga GraalVM, así que incluso una simulación en JavaScript corre sobre una JVM.

k6 se instala como paquete o como binario independiente, sin ningún otro entorno de ejecución. También ejecuta directamente archivos .ts, y su soporte de TypeScript elimina los tipos sin comprobarlos (comprobado el 9 de octubre de 2026).

¿Cómo se escribe la misma prueba en cada herramienta?

Las dos herramientas pueden expresar la misma prueba en JavaScript. Gatling la llama simulación y describe la carga con un perfil de inyección, y k6 la llama script y describe la carga con un escenario y su executor.

Esta es una prueba en la que llegan diez usuarios nuevos por segundo durante cinco minutos, y que falla si el percentil 95 supera los 500 ms o si falla más del 1 % de las peticiones. Con el SDK de JavaScript de Gatling, basada en su tutorial de la primera simulación:

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

La misma prueba en k6, con el executor constant-arrival-rate:

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
}

Se lanzan con npx gatling run y k6 run script.js.

¿Cómo modelan la carga Gatling y k6?

Las dos admiten modelos de carga abiertos y cerrados. En Gatling eliges con el método de inyección que llamas, y en k6 con el executor que configuras.

En Gatling, injectOpen recibe tasas de llegada como constantUsersPerSec, e injectClosed objetivos de concurrencia como constantConcurrentUsers. k6 tiene seis executors: los dos de tasa de llegada siguen el modelo abierto, y los otros cuatro el cerrado, en el que un usuario virtual solo empieza su siguiente iteración cuando termina la anterior.

Un escenario de k6 con tasa de llegada inicia las iteraciones desde un grupo de usuarios virtuales reservados de antemano, y cuando ese grupo se agota, k6 se salta iteraciones y las cuenta como iteraciones descartadas (comprobado el 9 de octubre de 2026). Nuestra guía sobre el modelo de carga abierto vs cerrado explica cuándo conviene cada uno.

¿Cómo deciden Gatling y k6 si una prueba ha pasado?

Las dos convierten los objetivos de rendimiento en un resultado de éxito o fallo con el que puede trabajar un pipeline de CI. Gatling comprueba sus objetivos cuando termina la ejecución, y k6 además puede detener una ejecución en cuanto se incumple un objetivo.

Las assertions de Gatling se evalúan después de la simulación, y una sola assertion fallida hace fallar la simulación y el build. Los thresholds de k6 terminan una ejecución fallida con un código de salida distinto de cero, y un threshold con abortOnFail detiene la prueba en el momento en que falla (comprobado el 9 de octubre de 2026).

¿Qué protocolos y pruebas de navegador cubre cada herramienta?

Las dos cubren HTTP y WebSockets de serie. Gatling añade Server-Sent Events y JMS, y k6 añade gRPC y sesiones reales de navegador.

Según el README de Gatling, gRPC, MQTT y GraphQL son componentes aparte con la Gatling Enterprise Component License, limitados sin Enterprise a cinco usuarios simultáneos y a pruebas de cinco minutos. k6 menciona HTTP/1.1, HTTP/2, WebSockets y gRPC como protocolos integrados, y suma otros mediante extensiones xk6 como Kafka y Redis.

Para pruebas de navegador, k6 tiene un módulo de navegador que controla un navegador basado en Chromium y recoge métricas del frontend. La documentación de Gatling no describe ningún motor de navegador: el Recorder de Gatling convierte una sesión de navegador o un archivo HAR en una simulación a nivel HTTP (comprobado el 9 de octubre de 2026).

¿Cómo se lanza una prueba más grande de lo que genera una máquina?

La edición open source de Gatling genera carga desde una sola máquina, y la ejecución distribuida requiere Gatling Enterprise. k6 puede repartir una prueba en un clúster de Kubernetes con el k6-operator, que es open source, o ejecutarla en Grafana Cloud k6.

La guía de instalación de Gatling pide una cuenta de Enterprise para la ejecución distribuida, que usa generadores de carga gestionados o ubicaciones privadas en tu propia cuenta de AWS, Azure, GCP o Kubernetes. El k6-operator reparte una prueba entre varias instancias de k6 dentro de un clúster (comprobado el 9 de octubre de 2026).

Hay un tercer camino para los scripts de k6. LoadFocus, que publica este sitio, ejecuta scripts de k6 en su propia infraestructura en la nube desde 25 regiones, con los usuarios y la duración tomados de la configuración de la prueba. 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 un script de modelo abierto como el de arriba no mantiene su tasa de llegada en LoadFocus. LoadFocus no ejecuta simulaciones de Gatling, de modo que para Gatling el camino hacia más máquinas es Gatling Enterprise.

¿Qué informes obtienes?

Gatling genera un informe HTML después de cada ejecución sin configurar nada. k6 muestra un resumen en la terminal y puede producir un informe HTML desde su panel web integrado.

El informe HTML de Gatling muestra en gráficos los percentiles del tiempo de respuesta, los usuarios iniciados por segundo y las peticiones por segundo a lo largo de la prueba. k6 muestra un resumen al final de la prueba, y su panel web enseña gráficos en directo y exporta un informe HTML autónomo cuando defines K6_WEB_DASHBOARD_EXPORT.

¿Cuál deberías elegir?

Gatling encaja con equipos que trabajan sobre la JVM, y k6 con equipos que quieren un único binario y JavaScript. Los protocolos, las pruebas de navegador y el escalado deciden casi todos los demás casos.

Elige Gatling en lugar de k6 cuando tu equipo trabaje sobre la JVM y quiera pruebas en Java, Kotlin o Scala construidas con Maven, Gradle o sbt junto al código de la aplicación, cuando necesites JMS o Server-Sent Events, o cuando quieras un informe HTML después de cada ejecución sin configurar nada.

Elige k6 en lugar de Gatling cuando quieras un único binario en CI sin JVM que instalar, cuando tus pruebas necesiten gRPC o sesiones reales de navegador, cuando los thresholds deban detener antes de tiempo una ejecución que falla, o cuando pienses escalar en Kubernetes con un operator open source.

FAQ

¿Es Gatling más rápido que k6? No lo hemos medido nosotros, así que no vamos a nombrar un ganador. La comparación justa es el mismo escenario con las dos herramientas en tu propio hardware.

¿Puede Gatling ejecutar scripts de k6? No según la documentación de Gatling, que no describe ninguna forma de ejecutar scripts de k6. Los dos SDK usan API distintas y los conversores de Gatling cubren JMeter y LoadRunner, así que un script de k6 hay que reescribirlo como simulación de Gatling, incluso con el SDK de JavaScript.

¿Puede LoadFocus ejecutar pruebas de Gatling? No. LoadFocus ejecuta scripts de k6 y planes de prueba de JMeter. Para repartir una simulación de Gatling entre varias máquinas, usa Gatling Enterprise.

Lecturas relacionadas

Prueba de carga de una API GraphQL: guía práctica

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Para hacer una prueba de carga de una API GraphQL, escribe un script con las operaciones que tus clientes envían de verdad, da a cada una su propio nombre en la herramienta de pruebas y mézclalas en las proporciones que ves en producción, con variables variadas. Revisa en cada cuerpo de respuesta si hay un array errors, porque un servidor GraphQL suele responder con HTTP 200 aunque parte de la operación haya fallado. Después sube la carga y juzga cada operación por sus propios percentiles.

Fuentes: graphql.org, el borrador de la especificación GraphQL over HTTP y la documentación de cada herramienta, todo comprobado el 9 de octubre de 2026.

Herramienta	Nombrar cada operación con	Hacer fallar una respuesta con `errors`	Alimentar variables desde
k6	`tags: { name: "..." }`	Un `check()` sobre el cuerpo parseado	`SharedArray`
JMeter	El nombre del sampler	JSON Assertion sobre `$.errors`, invertida	CSV Data Set Config
Gatling	`http("...")` o el plugin de GraphQL	`jsonPath("$.errors").notExists()`	Feeders
Artillery	Un `name` en la petición	`notHasProperty: "errors"`	`config.payload`

¿Por qué una API GraphQL necesita una prueba de carga distinta?

Porque todas las operaciones van a una sola URL y el trabajo que hay detrás depende de la consulta y de sus variables. Un informe agrupado por URL mete en el mismo saco una lectura barata y una búsqueda cara.

La guía Serving over HTTP de graphql.org dice que un servidor GraphQL funciona sobre un único endpoint, normalmente /graphql. Las operaciones llegan ahí por POST, con un cuerpo JSON que lleva query, un operationName opcional y variables.

¿Cómo se obtienen resultados por operación?

Pon a cada petición el nombre de su operación GraphQL y haz que la herramienta agrupe sus estadísticas por ese nombre. Cada herramienta tiene su propio ajuste para esto (comprobado el 9 de octubre de 2026).

k6: la guía de tags y grupos indica que se defina tags.name para dar a una petición un nombre con sentido, y los thresholds pueden apuntar a un solo tag, como http_req_duration{name:GetProduct}.
JMeter: el Aggregate Report crea una fila por cada petición con un nombre distinto. Desde JMeter 5.4, el sampler GraphQL HTTP Request tiene campos para Query, Variables y Operation Name.
Gatling: el nombre de la petición es la clave de sus estadísticas, y el plugin de GraphQL nombra las peticiones según la operación, por ejemplo query GetUser.
Artillery: el plugin metrics-by-endpoint informa por URL y añade a cada entrada el name de la petición, así que las operaciones con nombre aparecen por separado; useOnlyRequestNames: true quita la URL y deja solo el nombre.

¿Qué operaciones debe enviar la prueba?

Las que recibe producción, en las mismas proporciones. Saca el recuento de cada operación de los logs del servidor o de tu monitorización de GraphQL y conviértelo en una mezcla ponderada de lecturas y mutaciones.

Usa los documentos que envían tus clientes, con su profundidad real, en lugar de una consulta simplificada. Alimenta las variables desde un archivo de datos, para que el servidor busque muchos registros distintos en vez de devolver un único resultado en caché. Mantén también realista el número de operaciones distintas: la nota técnica de Apollo sobre pruebas de carga de GraphQL, un documento del propio fabricante, explica que cada operación nueva se analiza y se valida antes de ejecutarse, y desaconseja generar muchas más operaciones únicas de las que envían los clientes reales.

Las mutaciones cambian datos, así que ejecútalas donde puedas restaurarlos. La guía paso a paso de pruebas de carga explica los objetivos y la rampa de subida.

¿Por qué una respuesta HTTP 200 puede ser un fallo?

Porque GraphQL informa de los errores dentro del cuerpo de la respuesta. Una petición puede devolver el estado 200 con un array errors y datos parciales, y una comprobación del estado la da por buena.

La página Response de graphql.org explica que, cuando falla un resolver, la ejecución sigue y la respuesta trae data junto a errors. Su guía de HTTP añade que esa respuesta debe recibir aun así un estado 2xx, porque HTTP no tiene un código para el éxito parcial, y que algunos servidores antiguos responden 2xx incluso ante errores de validación. El borrador GraphQL over HTTP propone un estado propio, el 294, para el éxito parcial con el tipo de medio más reciente application/graphql-response+json.

En una prueba de carga esto perjudica dos veces. Los errores no se cuentan, y las peticiones que fallan rápido, como operaciones rechazadas por un límite de profundidad, rebajan los tiempos de respuesta.

¿Cómo se comprueba el array errors en cada herramienta?

Parsea el cuerpo JSON y haz fallar la petición cuando haya errors. Cada herramienta tiene una forma integrada de hacerlo.

En k6 basta con un check sobre el cuerpo parseado, y un threshold sobre la métrica checks hace fallar la ejecución, porque los checks por sí solos no cambian el código de salida de k6:

import http from "k6/http";
import { check, sleep } from "k6";
import { SharedArray } from "k6/data";

const URL = "https://staging.example.com/graphql";
const ids = new SharedArray("ids", () =>
  JSON.parse(open("./product-ids.json")));
const QUERY = `query GetProduct($id: ID!) {
  product(id: $id) { id name price }
}`;

export const options = {
  vus: 20,
  duration: "5m",
  thresholds: {
    checks: ["rate>0.99"],
    "http_req_duration{name:GetProduct}": ["p(95)<400"],
  },
};

function parse(res) {
  try { return res.json(); } catch (e) { return null; }
}

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const payload = JSON.stringify({
    query: QUERY,
    operationName: "GetProduct",
    variables: { id: id },
  });
  const res = http.post(URL, payload, {
    headers: { "Content-Type": "application/json" },
    tags: { name: "GetProduct" },
  });
  const body = parse(res);
  check(res, {
    "status is 2xx": (r) => r.status >= 200 && r.status < 300,
    "no GraphQL errors": () => body !== null && !body.errors,
  });
  sleep(1);
}

SharedArray carga los ID una sola vez para todos los usuarios virtuales. El try evita que un cuerpo que no es JSON, como la página de error de un proxy, corte la iteración.

En JMeter, añade una JSON Assertion con la ruta $.errors y marca "Invert assertion", para que la muestra falle cuando la ruta exista. Un JSON Extractor copia ID en variables para la siguiente operación.

En Gatling, añade .check(jsonPath("$.errors").notExists()), ambos de su referencia de checks. El plugin de GraphQL comprueba el estado y los errores por defecto, pero su página de instalación limita las ejecuciones con la Community Edition a 5 usuarios y 5 minutos (comprobado el 9 de octubre de 2026). Para pruebas más grandes sin Gatling Enterprise, usa peticiones HTTP normales con ese check.

En Artillery, el plugin expect ofrece notHasProperty: "errors", y reportFailuresAsErrors: true lleva las expectativas fallidas al informe. Un capture con una ruta json pasa un valor a la siguiente petición.

¿Qué vigilar además de los tiempos de respuesta?

La caché, las consultas persistidas y la carga de la base de datos por petición. Cualquiera de ellas puede hacer que una prueba vaya más rápido o más lento que producción por motivos ajenos a la capacidad.

La guía de rendimiento de graphql.org señala que las consultas enviadas por GET pueden aprovechar la caché HTTP y las CDN, y que las consultas persistidas permiten al cliente enviar un hash en lugar del documento completo. Si tus clientes lo hacen, la prueba también debe hacerlo. Si no, una prueba que repite una consulta con las mismas variables mide una caché que el tráfico real no encuentra. La nota técnica de Apollo añade que Apollo Server, Gateway y el GraphOS Router activan por defecto las consultas persistidas automáticas.

La misma guía describe el problema N+1: una lista cuyo resolver carga cada elemento por separado convierte una petición en muchas consultas a la base de datos, algo que suele resolverse agrupándolas con una herramienta como DataLoader. Vigila las consultas a la base de datos por segundo junto a las peticiones por segundo; si suben mucho más rápido al crecer la carga, sospecha de un resolver. Los límites de profundidad, de complejidad y de tasa también pueden saltar durante una prueba.

¿Desde dónde debe llegar la carga?

Desde una sola máquina mientras escribes el script y haces una prueba de humo, y desde la nube cuando necesitas más carga o tráfico desde varias regiones.

LoadFocus ejecuta scripts de k6 desde 25 regiones de la nube. Allí, el número de usuarios y la duración salen de la configuración de la prueba y no de las options del script, y los escenarios con tasa de llegada funcionan con un número fijo de usuarios en lugar de una tasa fija de peticiones, la diferencia que explica el artículo sobre el modelo de carga abierto y cerrado. LoadFocus también publica una plantilla para endpoints GraphQL con consultas complejas (en inglés).

FAQ

¿Una prueba de carga de GraphQL debe enviar las consultas por GET o por POST? Como lo hagan tus clientes. graphql.org solo permite GET para operaciones de tipo query, y las mutaciones deben usar POST. Si producción envía consultas persistidas por GET a través de una CDN, prueba también ese camino.

¿El mismo script sirve para probar la carga de las suscripciones de GraphQL? Normalmente no. graphql.org explica que las suscripciones son de larga duración y suelen ir por WebSockets o server-sent events, así que necesitan su propio escenario en una herramienta que soporte ese transporte.

¿Una respuesta parcial debe contar como petición fallida? En la mayoría de las pruebas, sí, porque el cliente recibió un error en parte de lo que pidió. Si algunos errores son esperables, como resultados no encontrados para registros borrados, comprueba esos códigos de error concretos y haz fallar el resto.

Lecturas relacionadas

Herramientas de benchmark HTTP: wrk, hey, oha, ab y más

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Las herramientas de benchmark HTTP de línea de comandos que usan la mayoría de los equipos son wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon y h2load. Usa wrk2 cuando necesites un ritmo de peticiones constante y latencias de cola fiables, hey u oha para una comprobación rápida que también hable HTTP/2, h2load cuando lo que pruebas es el propio HTTP/2 o HTTP/3, y autocannon si tu equipo trabaja con Node.js.

No hemos enfrentado estas herramientas entre sí, así que aquí no hay cifras de velocidad ni veredictos sobre cuál es la más «rápida». Los datos salen del repositorio, el manual o la página de versiones de cada proyecto (comprobados el 9 de octubre de 2026); los consejos sobre cuándo elegir cada una son nuestra opinión.

Herramienta	Escrita en	Licencia	Control del ritmo	HTTP/2	Última versión
wrk	C, scripts LuaJIT	Modified Apache 2.0	Ninguno	No documentado	Tag 4.2.0, feb. 2021
wrk2	C	Apache 2.0	Ritmo fijo (`-R`)	No documentado	Ninguna, último commit sep. 2019
hey	Go	Apache 2.0	Límite por worker (`-q`)	Sí	v0.1.5, ene. 2026
oha	Rust	MIT	Límite global (`-q`)	Sí, y HTTP/3	v1.16.0, ago. 2026
ab	C (Apache httpd)	Apache 2.0	Ninguno	No	httpd 2.4.69, oct. 2026
bombardier	Go	MIT	Límite (`-r`)	Sí	v2.0.2, mar. 2025
autocannon	Node.js	MIT	Límite (`-R`)	No	v8.0.0, oct. 2024
h2load	C++ (nghttp2)	MIT	Por cliente (`--rps`)	Sí, y HTTP/3	nghttp2 v1.70.0, jul. 2026
Vegeta	Go	MIT	Ritmo fijo (`-rate`)	Sí	v12.13.0, oct. 2025

¿Por qué importa que una herramienta fije el ritmo?

Una herramienta que mantiene un número fijo de conexiones envía menos en cuanto el servidor se ralentiza, y sus cifras de latencia dejan fuera el tiempo que las peticiones pasaron esperando. Una herramienta de ritmo fijo sigue enviando según lo previsto, y la ralentización aparece en los percentiles.

Casi todas las herramientas de esta lista trabajan con un número dado de conexiones o workers (-c), y cada uno espera una respuesta antes de enviar más. El README de wrk2 llama a este punto ciego Coordinated Omission y cronometra cada petición desde el momento en que debería haberse enviado. Vegeta también mantiene un ritmo constante; lo verás en nuestro repaso de herramientas de pruebas de carga open source. oha y autocannon pueden corregir su latencia por ese mismo efecto cuando fijas un ritmo, mientras que hey y bombardier documentan sus opciones de ritmo solo como límites.

¿Sigue valiendo la pena wrk?

Sí, para ver rápido cuánta carga puede lanzar una sola máquina contra un endpoint, siempre con la salvedad anterior. Su tag más reciente es de febrero de 2021.

wrk está escrito en C y mantiene un número fijo de conexiones abiertas repartidas entre varios hilos. Los scripts LuaJIT opcionales pueden construir peticiones, procesar respuestas y generar informes propios, y make lo compila junto con las versiones de LuaJIT y OpenSSL que incluye. Muestra la latencia media, la desviación estándar y el máximo; --latency añade los percentiles 50, 75, 90 y 99.

Elige wrk2 en su lugar si necesitas un ritmo de peticiones fijo o latencias de cola en las que puedas confiar durante una ralentización.

¿Cuándo necesitas wrk2 en lugar de wrk?

Cuando la pregunta es cómo se comporta la latencia a un ritmo de peticiones concreto. wrk2 mantiene ese ritmo constante y registra cada latencia en un HdrHistogram.

wrk2 añade a wrk un argumento de rendimiento (-R, peticiones por segundo). --latency muestra el espectro completo de percentiles y --u_latency añade las cifras sin corregir para comparar. Su README avisa de que las ejecuciones de menos de 10 a 20 segundos pueden no dar información útil por un periodo de calibración de 10 segundos, y describe el proyecto como experimental. No tiene versiones publicadas, y su Makefile genera un binario que también se llama wrk, así que conviene mantener los dos separados.

Elige oha o autocannon en su lugar si quieres un ajuste de ritmo con corrección de latencia en un proyecto que todavía se mantenga.

¿Son intercambiables hey y oha?

Para comprobaciones rápidas, en buena medida: las dos ejecutan un grupo de workers durante un número de peticiones o un tiempo, y las dos hablan HTTP/2. Se diferencian en cómo limitan el ritmo y en lo que ves mientras se ejecutan.

hey es un pequeño programa en Go con binarios listos para Linux, macOS y Windows y una fórmula de Homebrew. -q limita las peticiones por segundo de cada worker, -h2 activa HTTP/2, y el resumen incluye un histograma de tiempos de respuesta y una distribución de latencias, o CSV con -o csv.

oha está escrito en Rust, se inspira en hey y muestra una interfaz en directo en la terminal. Su -q fija un ritmo global, --latency-correction corrige la Coordinated Omission y --http-version acepta 1.1, 2 y, en una compilación experimental, 3. Se instala con cargo, Homebrew, winget o pacman, y puede escribir JSON o CSV.

Elige hey en su lugar si un límite por worker encaja con tu forma de pensar la carga; elige oha para HTTP/3, JSON o corrección de latencia.

¿Conviene seguir usando ab?

Para una comprobación rápida en una máquina donde ya está instalado, sí. ab viene con Apache HTTP Server, y su propio manual enumera limitaciones conocidas.

ab recibe un número de peticiones (-n) y un nivel de concurrencia (-c), no tiene opción de ritmo ni de HTTP/2, y solo usa KeepAlive con -k. Su salida termina con el porcentaje de peticiones servidas dentro de un tiempo dado, y puede escribir esos porcentajes en CSV (-e) o cada medición en un archivo para gnuplot (-g). La sección de errores del manual dice que ab no implementa HTTP/1.x por completo y advierte de que su análisis intensivo de cadenas puede hacer que acabes midiendo el rendimiento del propio ab.

Elige hey u oha en su lugar si necesitas HTTP/2, un límite de ritmo o keep-alive por defecto.

¿Para qué sirven bombardier y autocannon?

bombardier es una herramienta en Go con HTTP/2 opcional y límite de ritmo. autocannon encaja con equipos de Node.js, porque también funciona como biblioteca dentro de un script de Node.

bombardier usa por defecto el cliente fasthttp y cambia al cliente net/http de Go con --http1 o --http2. -r fija un límite de ritmo, -l muestra los percentiles 50, 75, 90 y 99, y -o json deja el resultado listo para procesarlo con otras herramientas.

autocannon se describe como una herramienta HTTP/1.1 con pipelining y HTTPS, y se instala con npm i autocannon -g. -R limita el ritmo global y -r el de cada conexión, y en cuanto fijas uno de los dos, la latencia se corrige por Coordinated Omission. Su tabla muestra los percentiles 2,5, 50, 97,5 y 99, -l los muestra todos y -j escribe JSON.

Elige autocannon en lugar de bombardier si tus benchmarks viven en una suite de pruebas de Node.js, y bombardier si necesitas HTTP/2.

¿Qué herramienta está pensada para HTTP/2 y HTTP/3?

h2load. Viene del proyecto nghttp2, prefiere HTTP/2 y puede forzar HTTP/1.1 o, si se compiló con soporte, HTTP/3.

h2load se compila junto con nghttp2 pasando --enable-app a ./configure. Además del número de clientes (-c), fija los flujos simultáneos por cliente (-m) para poner a prueba la multiplexación bajo carga, y --rps fija las peticiones por segundo de cada cliente. El manual da el mínimo, el máximo, la media, la mediana, el p95 y el p99 del tiempo de petición, del tiempo de conexión y del tiempo hasta el primer byte. El soporte de HTTP/3 figura como experimental.

Elige oha en su lugar si quieres HTTP/2 con menos opciones y una vista en directo.

¿Cuándo pasar de un benchmark a una prueba de carga de verdad?

Cuando la pregunta tiene que ver con recorridos de usuario, con más carga de la que puede generar una máquina o con tráfico que llegue desde donde están tus usuarios.

Todas estas herramientas envían peticiones sencillas desde una sola máquina, y la guía de h2load recuerda que el propio cliente puede convertirse en el cuello de botella. Pasa a una herramienta de pruebas de carga si necesitas inicios de sesión, recorridos de varios pasos o tiempo de reflexión, si el tráfico tiene que llegar desde varias regiones o si una prueba debe aprobar o fallar en la CI. Nuestra guía Cómo hacer una prueba de carga lo explica paso a paso, y k6 vs Artillery compara dos herramientas con scripts.

LoadFocus, el editor de este sitio, ejecuta pruebas de carga para webs y API desde 25 regiones en la nube, con JMeter, k6 o pruebas sin código. Si tu benchmark es una petición que ya envías con curl, su conversor de cURL a k6 gratuito la convierte en un script de k6 en tu propio navegador.

FAQ

¿Qué diferencia hay entre wrk y wrk2? wrk2 es un fork de wrk que envía peticiones a un ritmo constante fijado con -R y cronometra cada petición desde el momento en que debería haberse enviado. wrk mantiene ocupado un número fijo de conexiones y no tiene ajuste de ritmo.

¿Qué herramientas de benchmark HTTP admiten HTTP/2? Según su documentación, hey, oha, bombardier, h2load y Vegeta. wrk y wrk2 no lo documentan, autocannon se describe como una herramienta HTTP/1.1 y ab no tiene opción de HTTP/2.

Lecturas relacionadas

Ley de Little en pruebas de carga: dimensionar y comprobar

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

La ley de Little en pruebas de carga dice que el número medio de usuarios o peticiones dentro de un sistema es igual al ritmo al que lo atraviesan multiplicado por el tiempo medio que cada uno pasa en él: L = λW. Con un número fijo de usuarios virtuales, eso se convierte en usuarios = vueltas por segundo × (tiempo de respuesta + tiempo de reflexión), lo que te dice antes de una prueba si el plan puede alcanzar su tasa objetivo y, después, si los resultados cuadran. Trabaja con medias sobre un tramo estable de la prueba, así que no dice nada de los percentiles.

Los ejemplos de abajo son aritmética, sin ninguna prueba detrás. Los datos sobre herramientas salen de la documentación de cada proyecto, comprobada el 9 de octubre de 2026.

Término	Definición de Little	Usuarios virtuales fijos (modelo cerrado)	Tasa de llegada (modelo abierto)
L	Número medio de elementos en el sistema	Usuarios virtuales, esperando o en pausa	Iteraciones en curso
λ	Tasa media de llegada	Vueltas completadas por segundo	La tasa que fijas
W	Tiempo medio dentro del sistema	Tiempo de respuesta + tiempo de reflexión por vuelta	Duración de una iteración

¿Qué dice la ley de Little?

A largo plazo, el número medio de elementos en un sistema de colas es igual a su tasa media de llegada multiplicada por el tiempo medio que cada uno pasa en él. Si conoces dos de las tres magnitudes, puedes calcular la tercera.

John D. C. Little publicó la demostración en 1961 en Operations Research con el título A Proof for the Queuing Formula: L = λW. En su revisión por el 50.º aniversario, de 2011, escribe que se cumple en condiciones notablemente generales: para una sola cola o una red entera, para una subclase de elementos o para todos, y sea cual sea el orden de servicio. El mismo artículo traslada los términos a un servidor: peticiones en proceso, peticiones por segundo y tiempo de respuesta medio.

¿Qué significan L, λ y W en una prueba de carga?

Depende de dónde trazas el límite del sistema. Alrededor del servidor, L son las peticiones en curso y W el tiempo de respuesta; alrededor de la vuelta completa de un usuario virtual, L son todos los usuarios virtuales y W el tiempo de respuesta más el tiempo de reflexión.

En una prueba con modelo cerrado, cada usuario está siempre en algún punto de su vuelta: esperando una respuesta o haciendo una pausa entre dos pasos. Con el límite alrededor de la vuelta, todos cuentan como «dentro», λ es el ritmo al que terminan las vueltas y W la duración media de una vuelta, incluido el tiempo de reflexión que añade el script:

usuarios = vueltas por segundo × (respuesta + reflexión)

Alrededor del servidor, la misma ley da las peticiones en vuelo: peticiones por segundo × tiempo de respuesta medio, la cifra que tienen que absorber tus pools de conexiones y tus hilos de trabajo. Mantén los tres valores en el mismo límite y el mismo tramo de tiempo; mezclarlos da resultados plausibles y equivocados.

¿Cómo se dimensiona una prueba con modelo cerrado usando la ley de Little?

Convierte la tasa de peticiones objetivo en vueltas por segundo y multiplícala por la duración esperada de una vuelta: el resultado es el número de usuarios virtuales que necesita el plan. Usa el tiempo de respuesta que esperas con la carga objetivo, que suele ser mayor que el que ves con pocos usuarios.

Un ejemplo, solo aritmética. El objetivo son 100 peticiones por segundo, cada vuelta envía 4 peticiones que deberían tardar 0,5 segundos cada una, y el script hace 3 pausas de 2 segundos de media:

vueltas por segundo = 100 peticiones/s ÷ 4 peticiones = 25
duración por vuelta = 4 × 0,5 s + 3 × 2 s             = 8 s
usuarios virtuales  = 25 vueltas/s × 8 s              = 200

Toma 200 como mínimo. Si las respuestas tardan 1 segundo con esa carga, una vuelta dura 10 segundos y el mismo objetivo necesita 250 usuarios.

¿Por qué los mismos usuarios envían menos peticiones cuando el sistema se ralentiza?

El número de usuarios es fijo, así que cuando una vuelta se alarga, las vueltas por segundo tienen que bajar. La carga cae justo cuando el sistema empieza a sufrir.

Mantén los 200 usuarios y haz que cada petición tarde 2 segundos. Una vuelta dura ahora 4 × 2 + 6 = 14 segundos, y 200 ÷ 14 da unas 14,3 vueltas, o unas 57 peticiones por segundo. La prueba sigue mostrando 200 usuarios mientras funciona a poco más de la mitad de la tasa prevista. El artículo sobre el modelo de carga abierto vs cerrado explica por qué eso oculta la saturación; la ley de Little predice el tamaño de la caída.

También muestra cómo se ve un límite de capacidad. Cuando la tasa de peticiones ya no puede subir, cada usuario extra solo añade espera: con un techo de 25 vueltas por segundo, 300 usuarios suponen 12 segundos por vuelta y 400 usuarios, 16. El gráfico de LoadFocus tiempo de respuesta vs usuarios virtuales representa el tiempo de respuesta medio y máximo frente al número de usuarios virtuales activos, un punto por cada nivel alcanzado, y ahí es donde aparece esa subida constante.

¿Cómo se comprueba una prueba terminada con la ley de Little?

Toma la tasa de peticiones y el tiempo de respuesta medios de un tramo en el que el número de usuarios se mantuvo estable, reconstruye a partir de ellos el número de usuarios y compáralo con lo que configuraste. Una diferencia grande significa que parte del tiempo se escapa de tus cifras.

Otro ejemplo aritmético. Una prueba mantiene 200 usuarios y registra 80 peticiones por segundo con una media de 0,6 segundos, con las mismas 4 peticiones y 6 segundos de pausas por vuelta. Son 20 vueltas por segundo de 4 × 0,6 + 6 = 8,4 segundos cada una, suficiente para 168 usuarios. Los 32 restantes significan que cada vuelta duró en realidad 10 segundos, así que hay unos 1,6 segundos por vuelta sin explicar. Dónde buscar:

El establecimiento de conexiones. En k6, http_req_duration deja fuera la resolución DNS y la conexión (referencia de métricas, comprobada el 9 de octubre de 2026).
El generador de carga. Un generador saturado retrasa el script entre peticiones.
El tiempo de reflexión. Las pausas aleatorias pueden durar de media más de lo previsto.
La ventana. Si se solapa con una rampa, hubo de media menos usuarios activos.

k6 también mide la vuelta directamente: vus cuenta los usuarios virtuales activos e iteration_duration la duración de una iteración completa, así que los usuarios activos deberían quedar cerca de las iteraciones por segundo × la duración media de una iteración.

¿Qué pasa con las pruebas por tasa de llegada?

La ley se cumple con el límite alrededor de cada iteración: las iteraciones en curso son iguales a la tasa de llegada por la duración de una iteración. Ese es el número de usuarios virtuales que la herramienta tiene que tener listos.

La guía de k6 sobre la asignación de VU para los ejecutores de tasa de llegada los estima como la duración mediana de una iteración × la tasa, más una constante para la variabilidad (comprobado el 9 de octubre de 2026). Es la ley de Little con la mediana en lugar de la media; unas pocas iteraciones lentas suben la media por encima de la mediana, por eso importa el margen.

LoadFocus ejecuta scripts de k6 en su nube, y allí los escenarios de tasa de llegada se ejecutan con un número fijo de usuarios; el validador de scripts lo avisa cuando añades un script así. Dimensiona esas pruebas con el cálculo del modelo cerrado de arriba y cuenta con que la tasa baje si las respuestas se ralentizan.

¿Dónde deja de funcionar la ley de Little?

Relaciona medias sobre un tramo en el que el sistema está en equilibrio. Los percentiles, las ventanas cortas y las rampas quedan fuera.

Solo medias. Una prueba puede cumplir la ley mientras una de cada veinte peticiones espera diez veces la media; juzga también los resultados por percentiles.
Un tramo estable. La demostración de 1961 supone un proceso estacionario, y la revisión de 2011 muestra que la fórmula también es exacta en una ventana finita que empieza y termina vacía. Una meseta de prueba no es ninguna de las dos cosas, así que elige una larga, en la que tantos usuarios terminen vueltas como las empiecen.
Rampas. Mientras se añaden usuarios, el pico configurado no es L: usa la media temporal de usuarios de la ventana o deja la rampa fuera.
Errores. Los fallos rápidos cuentan como peticiones completadas con tiempos cortos, así que un sistema que falla puede seguir cuadrando la ecuación. Revisa primero la tasa de errores.

FAQ

¿La ley de Little necesita llegadas de Poisson o un tipo de cola concreto? No. Las demostraciones de la revisión de Little no suponen nada sobre el patrón de llegadas ni sobre los tiempos de servicio, y el resultado se cumple sea cual sea el orden de servicio. Solo hace falta que las medias existan en el periodo que mides.

¿Puede la ley de Little predecir el tiempo de respuesta p95? No. Relaciona tres medias, así que puede comprobar un tiempo de respuesta medio, pero no dice nada sobre la forma de la distribución ni sobre el pequeño porcentaje más lento.

Lecturas relacionadas

Criterios de aprobación en pruebas de carga: cómo fijarlos

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Los criterios de aprobación en pruebas de carga son los pocos límites que una ejecución debe cumplir para darse por aprobada: un percentil de latencia para las peticiones que esperan los usuarios, una tasa de errores y una tasa mínima de peticiones, todo con una carga determinada. Saca los límites de un objetivo de nivel de servicio (SLO), coloca dentro de ellos límites de regresión tomados de ejecuciones anteriores y deja que el código de salida de la herramienta haga fallar la ejecución solo por esos límites estrictos. Todo lo demás es un aviso que lee una persona.

Los datos sobre las herramientas se comprobaron el 9 de octubre de 2026 en la documentación de cada proyecto, y cada límite que aparece es un ejemplo.

Criterio	Límite de ejemplo	De dónde sale el número	Si no se cumple
p95 de latencia, pago	Menos de 400 ms	SLO de latencia menos un margen	Fallo
p99 de latencia, pago	Menos de 1200 ms	Ejecuciones anteriores de esta prueba	Aviso
Tasa de errores	Menos del 0,5 %	SLO de disponibilidad	Fallo
Peticiones por segundo	Al menos el 95 % del plan	La carga prevista	Fallo
CPU del generador de carga	Menos del 80 %	Herramienta o plataforma	Ejecución no válida

¿Qué hace que una prueba de carga se apruebe o falle?

Una ejecución se aprueba cuando todos los límites estrictos se cumplen con la carga prevista, y falla en cuanto uno no se cumple. No es válida cuando la propia prueba no hizo su trabajo, digan lo que digan los números.

Un generador de carga saturado, una carga que nunca llegó a su objetivo o un script con errores producen números sobre el montaje de la prueba. LoadFocus, por ejemplo, muestra un aviso de saturación del generador de carga cuando algún motor alcanzó o superó el 80 % de CPU en su pico. Los códigos de salida de k6 separan los casos para la CI: 99 indica umbrales incumplidos y 107 una excepción en el script (comprobado el 9 de octubre de 2026).

¿Cómo se convierte un SLO en criterios de prueba de carga?

Reformula cada SLO que la carga puede romper, normalmente latencia y disponibilidad, como un límite sobre lo que mide la prueba, y hazlo más estricto que el SLO para que aprobar deje margen.

El libro de SRE de Google define un SLO como un valor objetivo o un rango de valores para un nivel de servicio medido por un indicador (SLI), con ejemplos como: el 99 % de las llamadas Get terminan en menos de 100 ms. Pide que un SLO diga cómo se mide y en qué condiciones es válido, y recomienda un margen de seguridad: un objetivo interno más estricto que el que se promete a los usuarios.

En una prueba de carga, esas condiciones son la carga y la mezcla de peticiones. «El 95 % de las llamadas de pago en menos de 500 ms» podría convertirse, por ejemplo, en «p95 del pago por debajo de 400 ms con 300 peticiones por segundo durante 15 minutos». Si aún no hay SLO, acuerda uno provisional con el responsable de producto.

¿Qué métricas deben cubrir los criterios?

La latencia de las peticiones que esperan los usuarios, una tasa de errores, la tasa de peticiones alcanzada y, sobre todo como avisos, los recursos de los servidores.

Latencia por tipo de petición. Un percentil global mezcla un health check rápido con una búsqueda lenta. En k6, las peticiones etiquetadas crean submétricas con sus propios límites; en Gatling, details() apunta a una petición o un grupo. Una prueba que frenó su propia carga da percentiles demasiado favorables (coordinated omission).
Errores, en sentido amplio. Un 200 rápido con una página de error sigue siendo un fallo, así que comprueba el contenido. Una Response Assertion de JMeter que falla marca su muestra como no exitosa; los checks de k6 solo afectan al código de salida a través de un umbral.
Un mínimo de tasa de peticiones. En un modelo de carga cerrado, un sistema lento recibe menos peticiones, de modo que una ejecución puede cumplir sus límites de latencia con una fracción de la carga prevista (modelo de carga abierto vs cerrado).
Recursos de los servidores. CPU, memoria y uso de pools salen de tu monitorización. Trátalos como avisos salvo que un plan de capacidad fije un techo estricto.

¿Cómo se eligen los números?

El techo sale del SLO y el límite de regresión, de ejecuciones anteriores de la misma prueba. El SLO dice lo que toleran los usuarios; las ejecuciones anteriores, lo que este build hace normalmente.

El libro de SRE desaconseja fijar un SLO a partir del comportamiento actual. Un límite de regresión existe para detectar cambios, así que el comportamiento actual es justo su materia prima. Ejecuta varias veces el build sin cambios con el mismo entorno y la misma carga, anota cuánto varía cada métrica y pon el límite por encima de la peor ejecución con algo de margen, siempre por debajo del techo derivado del SLO cuando lo haya.

Si las ejecuciones de un mismo build varían más que la regresión que quieres detectar, la prueba es demasiado ruidosa para bloquear builds: alarga primero la fase estable o aísla el entorno. Registra nuevas ejecuciones de referencia tras cualquier cambio deliberado.

¿Qué criterios deben hacer fallar el build y cuáles solo avisar?

Haz fallar el build con los límites que vienen de un SLO o que comprueban que las respuestas son correctas. Avisa con los percentiles de cola, el uso de recursos y las derivas lentas, que piden criterio; una barrera que falla por ruido acaba desactivada pronto.

El plugin ensure de Artillery tiene un nivel de aviso: una condición con strict: false es opcional, así que incumplirla no cambia el código de salida (comprobado el 9 de octubre de 2026). En k6, un check sin umbral nunca hace fallar la ejecución. En el resto de herramientas, deja los avisos fuera de las aserciones.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

¿Cuándo debe detenerse antes de tiempo una prueba de carga?

Cuando seguir solo puede hacer daño o ya no demuestra nada: errores muy por encima del límite, un sistema ya caído o un generador que no da abasto. Dale a la regla un periodo de gracia para que el ruido del arranque no la dispare.

Haz las reglas de parada más laxas que los límites de aprobación: protegen un entorno compartido. En k6, abortOnFail detiene la prueba en cuanto falla un umbral, tras un delayAbortEval opcional. La documentación de Locust sobre extensiones muestra un greenlet en segundo plano que detiene la ejecución cuando la proporción de fallos supera un umbral. En Gatling, crashLoadGeneratorIf detiene el generador con un código de fallo cuando se cumple una condición en la sesión de un usuario virtual. Un Thread Group de JMeter puede detener la prueba ante un error de sampler, algo adecuado para una comprobación de corrección (todo comprobado el 9 de octubre de 2026).

¿Cómo codifica cada herramienta los criterios?

k6 y Artillery convierten un límite estricto incumplido en un código de salida distinto de cero, Locust lo hace ante cualquier petición fallida o con los límites que programes tú, y las aserciones de Gatling hacen fallar el build. JMeter deja el veredicto a un paso posterior a la ejecución.

k6: los umbrales van en las opciones del script. Este ejemplo falla por el p95 de las peticiones etiquetadas name: checkout o por un 0,5 % de errores, y se detiene pasado un minuto si los errores superan el 5 %:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: las aserciones combinan un ámbito (global, forAll, details), una estadística como un percentil o requestsPerSec, y una condición. Se evalúan al terminar la ejecución, y una sola aserción fallida hace fallar la simulación.

Locust termina con código 1 si alguna petición falló, y --exit-code-on-error cambia ese código. Para una proporción o un percentil, asigna environment.process_exit_code en un listener de quitting; el código fuente de Locust da prioridad a ese valor.

JMeter juzga cada muestra con sus aserciones, y sus opciones de línea de comandos no incluyen ningún límite para la ejecución completa. Decide la CI: con un script corto sobre el archivo de resultados, como en nuestra guía de GitHub Actions, o con el jmeter-maven-plugin, un plugin de terceros cuyo goal results hace fallar el build si falla una sola muestra, salvo que errorRateThresholdInPercent fije una tasa (comprobado el 9 de octubre de 2026).

LoadFocus evalúa las ejecuciones según umbrales de aprobado o fallo guardados en la prueba: tiempos de respuesta p95 y p99 máximos, tasa de errores máxima y tasa mínima de peticiones, cada uno opcional. Cada ejecución recibe una insignia PASS o FAIL con los valores reales y los objetivos, y una API entrega el veredicto a un pipeline. LoadFocus ejecuta los escenarios de k6 con tasa de llegada con un número fijo de usuarios, así que ahí un mínimo de tasa comprueba lo que lograron esos usuarios.

FAQ

¿Debe ser el tiempo de respuesta medio un criterio de aprobación? Rara vez. El libro de SRE prefiere los percentiles: una media oculta la cola larga y puede quedarse plana mientras las peticiones más lentas se vuelven mucho más lentas.

¿Cuántos criterios de aprobación debe tener una prueba de carga? Un puñado de límites estrictos, más avisos. El libro de SRE aconseja tener los menos SLO posibles y dice que, si citar uno nunca permite ganar una discusión sobre prioridades, probablemente no merece la pena tenerlo. Aplica la misma regla a cada límite de una prueba de carga.

¿Puede aprobarse una prueba de carga con algunas peticiones fallidas? Sí, si la tasa de errores se mantiene por debajo de su límite. Revisa el comportamiento por defecto de tu herramienta: Locust hace fallar la ejecución con una sola petición fallida.

Lecturas relacionadas

Pruebas de carga en GitHub Actions: guía práctica

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Para hacer pruebas de carga en GitHub Actions basta un archivo de workflow: instalar la herramienta, lanzar una prueba corta contra una URL de staging y dejar que el código de salida de la herramienta haga fallar el job cuando no se cumple un umbral. Sube los resultados como artefacto para que cada ejecución deje constancia. Mantén la prueba pequeña, porque un runner estándar alojado por GitHub es una sola máquina virtual con pocos núcleos de CPU.

Los datos sobre las herramientas y sobre GitHub salen de la documentación de cada proveedor, comprobados el 9 de octubre de 2026, y los workflows siguen ese uso documentado.

Herramienta	Se instala con	Qué hace fallar el job	Resultados que conservar
k6	`setup-k6-action` de Grafana	Un umbral incumplido	Salida JSON
Artillery	`artilleryio/action-cli`	Una comprobación `ensure` fallida	`report.json`
Locust	`pip install locust`	Cualquier petición fallida o una regla propia	Archivos CSV y HTML
JMeter	El archivo de la versión	Nada integrado: añade un paso de control	Archivo `.jtl` e informe HTML

¿Qué necesita un workflow de pruebas de carga?

Un disparador, un runner, un paso que instale la herramienta, un paso que ejecute la prueba con umbrales y un paso que suba los resultados. Todo lo demás es opcional.

Guarda el script de prueba en el repositorio, por ejemplo en tests/load/. Lee la URL de staging de una variable del repositorio mediante el contexto vars y fija timeout-minutes en el job: el valor por defecto es de 360 minutos (comprobado el 9 de octubre de 2026).

¿Qué eventos deberían lanzar una prueba de carga?

Ejecuta una prueba corta en los pull requests y otra más larga de forma programada o a mano.

Usa pull_request para detectar una regresión antes del merge, workflow_dispatch para ejecuciones manuales y schedule para ejecuciones cron (en UTC, salvo que indiques una zona horaria). La referencia de eventos de GitHub añade algunos límites (comprobado el 9 de octubre de 2026): las programaciones solo se ejecutan en la rama por defecto, como mucho cada cinco minutos, y pueden retrasarse al comienzo de cada hora. Los pull requests desde forks no reciben secretos, salvo GITHUB_TOKEN.

¿Cómo se ejecuta k6 en GitHub Actions?

Usa las dos acciones oficiales de Grafana, una para instalar k6 y otra para ejecutar el script. El paso falla en cuanto k6 termina con un código de salida distinto de cero, que es lo que provoca un umbral incumplido.

Tanto setup-k6-action como run-k6-action están en v1 (comprobado el 9 de octubre de 2026):

name: load-test
on:
  pull_request:
  workflow_dispatch:

jobs:
  k6:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
    steps:
      - uses: actions/checkout@v7
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: tests/load/smoke.js
          flags: --out json=results.json
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: k6-results
          path: results.json
          retention-days: 14

Los umbrales viven en el script, que lee BASE_URL del entorno:

import http from "k6/http";

export const options = {
  vus: 10,
  duration: "1m",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  http.get(`${__ENV.BASE_URL}/health`);
}

La documentación de k6 aclara que los checks no afectan al código de salida, así que la decisión de aprobar o suspender tiene que venir de los umbrales.

¿Cómo se ejecutan Artillery, Locust o JMeter en su lugar?

Cambia los pasos de instalación y ejecución, conserva el resto del workflow y usa el mecanismo propio de cada herramienta para fallar cuando no se alcanza un objetivo.

Artillery tiene una GitHub Action oficial cuyo README indica que @v2 sigue la última versión 2.x (comprobado el 9 de octubre de 2026). El paso es uses: artilleryio/action-cli@v2 con command: run --target ${{ vars.STAGING_URL }} tests/load/api.yml --output report.json, y el plugin ensure hace que Artillery termine con un código distinto de cero cuando no se alcanza un objetivo. La sección config del script:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500

Locust termina con código 1 si alguna petición falló, y para reglas de latencia fijas environment.process_exit_code en un listener del evento quitting, como muestra esa misma página (comprobado el 9 de octubre de 2026). Después de actions/setup-python@v7 con python-version: "3.13":

      - run: pip install locust
      - run: >
          locust -f tests/load/locustfile.py --headless
          -u 20 -r 5 -t 2m -H "$BASE_URL"
          --csv results --html report.html

JMeter se ejecuta sin interfaz gráfica con -n, y las opciones de línea de comandos de su manual no incluyen ningún umbral de aprobado o suspenso (comprobado el 9 de octubre de 2026). Un paso corto puede leer el archivo de resultados, en CSV con una columna success por defecto, y hacer fallar el job por su cuenta:

      - uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: "21"
      - name: Install JMeter 5.6.3
        env:
          JM_BASE: https://archive.apache.org/dist/jmeter/binaries
        run: curl -sSL "$JM_BASE/apache-jmeter-5.6.3.tgz" | tar -xzf -
      - name: Run the test plan
        run: >
          apache-jmeter-5.6.3/bin/jmeter -n -t tests/load/plan.jmx
          -l results.jtl -e -o report
      - name: Fail above 1% errors
        run: |
          python3 - <<'EOF'
          import csv, sys
          rows = list(csv.DictReader(open("results.jtl")))
          bad = sum(r["success"] != "true" for r in rows)
          print(f"{bad} of {len(rows)} samples failed")
          sys.exit(1 if not rows or bad > 0.01 * len(rows) else 0)
          EOF

¿Cómo se hace fallar el job cuando la prueba no alcanza un objetivo?

Escribe los objetivos en la prueba como umbrales y deja que el código de salida haga el resto. GitHub marca un paso como fallido cuando su comando termina con un código distinto de cero, y el job falla con él.

Empieza con una tasa de errores estricta y un percentil de latencia generoso, y ajusta el límite de latencia cuando sepas cuánto varían tus cifras entre ejecuciones. La guía paso a paso de pruebas de carga explica cómo elegir esos objetivos.

¿Dónde deben quedar los resultados de cada ejecución?

Súbelos como artefacto del workflow, con if: always() para que una prueba fallida conserve igualmente su informe. Los artefactos se guardan 90 días por defecto, y retention-days acorta ese plazo.

El README de upload-artifact documenta los 90 días por defecto (comprobado el 9 de octubre de 2026). Fija if-no-files-found: error para que un informe ausente haga fallar el paso de forma visible.

¿Cuánta carga puede generar un runner alojado por GitHub?

Suficiente para una prueba de humo o un pequeño control de regresiones. Un runner Linux estándar tiene 4 CPU y 16 GB de RAM en repositorios públicos, 2 CPU y 8 GB en privados, y un job se detiene a las 6 horas.

Esas cifras salen de la referencia de runners y de los límites de Actions de GitHub (comprobado el 9 de octubre de 2026), que no dan ninguna cifra de ancho de banda de red.

Un job corre en una sola máquina, así que es un único generador de carga: si su CPU se satura, los tiempos de respuesta incluyen el tiempo de espera en el propio runner. Además, todas las peticiones salen de esa máquina, de modo que los limitadores de tasa que cuentan por dirección de cliente ven un único cliente muy activo. GitHub desaconseja usar en listas de permitidos los rangos de IP de Azure de sus runners Ubuntu; los runners más grandes (larger runners) de los planes Team y Enterprise Cloud añaden CPU, memoria y direcciones IP estáticas.

¿Cuándo debe venir la carga de otro sitio?

Cuando necesitas más carga de la que produce una máquina, tráfico desde varias regiones o ejecuciones más largas que el límite de un job.

Con k6, run-k6-action ejecuta la prueba en Grafana Cloud k6 si fijas cloud-run-locally: false y pasas K6_CLOUD_TOKEN, K6_CLOUD_PROJECT_ID y, con k6 v2, K6_CLOUD_STACK_ID. Una ejecución en la nube ignora por defecto el entorno del runner, así que añade -e BASE_URL=${{ vars.STAGING_URL }} a flags (comprobado el 10 de octubre de 2026). La acción de Artillery puede llamar a run-fargate o run-lambda para generar la carga desde tu propia cuenta de AWS (ambos comprobados el 9 de octubre de 2026). La comparativa k6 vs Artillery cubre ambas.

Para JMeter, LoadFocus documenta una integración con GitHub Actions basada en su cliente npm. Guardas la prueba en tu cuenta de LoadFocus, añades la clave de API y el ID de equipo como secretos y llamas a run-test. Las opciones de abajo siguen la ayuda del cliente:

      - run: npm install -g @loadfocus/loadfocus-api-client
      - env:
          LF_KEY: ${{ secrets.LOADFOCUS_API_KEY }}
          LF_TEAM: ${{ secrets.LOADFOCUS_TEAM_ID }}
        run: |
          test -n "$LF_KEY"
          test -n "$LF_TEAM"
          loadfocus-api config set \
            --apikey "$LF_KEY" --teamid "$LF_TEAM"
          loadfocus-api jmeter run-test --name checkout-api \
            --thresholds "avgresponse<=200,errors==0,p95<=250"

El cliente espera hasta 1.800 segundos por defecto (--wait-timeout lo cambia), así que da al job un timeout-minutes de más de 30, por ejemplo 40. Termina con código 1 cuando no se cumple un umbral y con 0 cuando falta la clave de API o el ID de equipo, por eso las líneas test -n hacen fallar el paso antes si un secreto está vacío. La carga sale de LoadFocus, que ejecuta scripts de JMeter desde 25 regiones en la nube.

FAQ

¿Cuánto debe durar una prueba de carga en un pull request? Unos pocos minutos: lo bastante para superar la rampa de subida y obtener un percentil estable, y lo bastante poco para que nadie tenga que esperarla.

¿Está permitido hacer pruebas de carga desde runners alojados por GitHub? Las condiciones de GitHub para Actions prohíben perturbar cualquier servicio y limitan los runners alojados al trabajo sobre el propio proyecto del repositorio (comprobado el 9 de octubre de 2026). Probar el entorno de staging de ese mismo proyecto, sin sobrecargar los servidores de GitHub, es el tipo de prueba que describen esas condiciones.

¿Puedo usar un runner autoalojado en su lugar? Sí. Funciona en tu propio hardware y en tu red, y la página de límites de GitHub permite que un job dure ahí hasta 5 días. Sigue siendo un único generador de carga.

Lecturas relacionadas

Pruebas de carga con Locust: análisis de la herramienta

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Locust es una herramienta de pruebas de carga en Python, gratuita y con licencia MIT, en la que cada prueba es un programa de Python, ejecutado por usuarios ligeros desde una interfaz web o la línea de comandos. Las pruebas de carga con Locust encajan con equipos que escriben Python y prueban sobre todo servicios HTTP. A quien necesite muchos protocolos de serie o un editor gráfico de pruebas le irá mejor JMeter, y a quien escriba JavaScript, k6.

No hemos ejecutado Locust para este análisis. Los datos salen de la documentación, el repositorio y la página de PyPI de Locust, comprobados el 9 de octubre de 2026, y las valoraciones son nuestras.

Tema	Locust
Licencia	MIT
Entorno	Python 3.11 o posterior
Versión actual	2.46.7 (4 de octubre de 2026)
Formato de las pruebas	Clases de Python en un locustfile
Ejecución	Interfaz web en el puerto 8089, o headless
Protocolos integrados	HTTP y HTTPS
Escalado	Un master y tantos workers como quieras
Resultados	Gráficos en vivo, CSV, HTML, JSON, OpenTelemetry
CI	Código de salida 1 si falla alguna petición

¿Quién desarrolla Locust y sigue manteniéndose?

Lars Holmberg mantiene Locust y Microsoft patrocina ese trabajo. Las versiones salen a menudo: 17 en lo que va de 2026.

El README de Locust nombra a ambos. PyPI muestra la 2.46.7, publicada el 4 de octubre de 2026, como última versión, y exige Python 3.11 o posterior (comprobado el 9 de octubre de 2026).

¿Cómo funciona un locustfile?

Un locustfile es un módulo de Python normal con al menos una clase de usuario. Cada usuario simulado ejecuta sus tareas una tras otra y hace una pausa entre ellas según su wait_time.

Según la guía del locustfile, HttpUser da a cada usuario un client que envuelve python-requests, conserva las cookies y registra cada petición. Los métodos marcados con @task se eligen al azar, ponderados por el número del decorador, y on_start se ejecuta una vez por usuario. Este usuario inicia sesión, navega por el catálogo cuatro veces más de lo que compra y lanza como mucho una tarea cada 10 segundos:

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

catch_response te permite dar por fallida una petición según su contenido, y name agrupa las URL variables en una sola fila de estadísticas. Las demás funciones de espera son constant, between, constant_throughput y, desde la versión 2.46.6, poisson; nuestra guía sobre el tiempo de reflexión en pruebas de carga explica cómo esas pausas dan forma a la carga. La documentación añade que el tiempo de espera solo puede limitar el rendimiento y no lanza usuarios nuevos para alcanzar un ritmo objetivo. Una prueba de Locust es, por tanto, un grupo fijo de usuarios: un modelo de carga cerrado.

¿Conviene usar la interfaz web o el modo headless?

La interfaz web mientras exploras y el modo headless para ejecuciones repetibles.

El comando locust arranca una interfaz web en el puerto 8089. Allí indicas el host, los usuarios y la rampa de subida, sigues gráficos en vivo y cambias la carga a mitad de prueba. El modo headless recibe los mismos ajustes como opciones:

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u fija los usuarios, -r cuántos arrancan por segundo y -t la duración, con la rampa de subida incluida. Los mismos ajustes funcionan también en locust.conf o pyproject.toml.

¿Cómo funciona el modo distribuido?

Un proceso master gestiona la interfaz web y coordina, mientras los procesos worker ejecutan los usuarios y le envían sus estadísticas. Necesitas un worker por núcleo de CPU, porque un proceso de Python no puede aprovechar del todo más de un núcleo.

Según la documentación de carga distribuida, un solo proceso supera las mil peticiones por segundo con un plan de prueba sencillo, así que las pruebas más grandes se reparten:

# en la máquina master
locust -f locustfile.py --master
# en cada máquina worker, un worker por núcleo
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - descarga el locustfile desde el master. --processes depende de fork(), así que no funciona en Windows, y cada cambio en el locustfile obliga a reiniciar todos los procesos. La documentación cubre además un operador de Kubernetes y Azure Load Testing (comprobado el 9 de octubre de 2026).

LoadFocus, el editor de este sitio, no ejecuta pruebas de Locust. Ejecuta planes de prueba de JMeter y scripts de k6 desde 25 regiones en la nube, así que para Locust las vías de arriba siguen siendo las formas de escalar.

¿Puede Locust probar protocolos distintos de HTTP?

Sí, si aportas un cliente de Python para el protocolo. Solo HTTP y HTTPS vienen integrados.

La página sobre otros protocolos muestra cómo envolver un cliente para que cada llamada quede registrada, con ejemplos para XML-RPC y gRPC y clases de usuario experimentales para MQTT, Socket.IO y OpenAI. El proyecto aparte locust-plugins añade usuarios para Kafka, FTP, Selenium y Playwright (comprobado el 9 de octubre de 2026).

Para HTTP existe también FastHttpUser, que usa geventhttpclient y consume mucha menos CPU. En el mejor caso, según la documentación, un proceso llega a unas 16.000 peticiones por segundo, frente a 4.000 con HttpUser. FastHttpUser no hace más rápida cada petición, y por defecto no verifica los certificados TLS.

¿Qué informes da Locust y cómo encaja en la CI?

Obtienes gráficos en vivo en la interfaz web y, si los pides, archivos de resultados. En la CI, Locust termina con código 1 si alguna petición falló.

Según la referencia de configuración, --csv escribe archivos de estadísticas, historial y fallos, --html guarda un informe y --json imprime las estadísticas finales. --otel exporta a un backend de OpenTelemetry. La documentación del modo headless muestra un listener que hace fallar la ejecución según la tasa de fallos, el tiempo de respuesta medio o el percentil 95, y nuestra guía de pruebas de carga en GitHub Actions lo integra en un workflow.

¿Qué hace bien Locust y dónde están sus límites?

Destaca en la lógica de las pruebas y con muchos usuarios simultáneos que pasan casi todo el tiempo esperando. Es más flojo en peticiones por proceso y en los protocolos que tienes que conectar por tu cuenta.

Como las pruebas son Python puro, los bucles, las condiciones, los datos generados y tu propio cliente de API funcionan sin más, y las pruebas viven en el control de versiones. La página What is Locust explica que el bajo coste de cada usuario encaja con cargas muy concurrentes, aunque admite que otras herramientas pueden enviar más peticiones por segundo con el mismo hardware.

Los límites que reconoce la propia documentación:

Un proceso de Python usa un solo núcleo de CPU.
Las bibliotecas que hacen E/S en C bloquean el proceso, salvo que gevent pueda parchearlas.
HttpUser no analiza HTML ni carga los recursos de la página.
El tiempo de espera no puede añadir usuarios para sostener un ritmo de peticiones.

¿Qué otras herramientas de Python hay para pruebas de carga?

Locust es el motor de Python con desarrollo activo. Molotov, la principal alternativa, no publica ninguna versión en PyPI desde 2022, y Taurus ejecuta Locust con uno de sus ejecutores.

Molotov es una herramienta para Python 3.8+ construida sobre asyncio y aiohttp; su última versión en PyPI es la 2.6, del 21 de octubre de 2022, y el último commit de su rama principal es de noviembre de 2023 (comprobado el 21 de octubre de 2026). Taurus ejecuta un locustfile, o peticiones GET y POST sencillas escritas en YAML, con su ejecutor locust. Locust lo instalas tú, en modo distribuido Taurus solo arranca el master y su ajuste throughput no tiene efecto con este ejecutor (comprobado el 21 de octubre de 2026).

¿Cuándo elegir k6, JMeter o Gatling en lugar de Locust?

Elige otra herramienta cuando su lenguaje, sus protocolos o su modelo de carga encajen mejor con tu equipo.

Nuestro repaso de herramientas de pruebas de carga open source pone Locust junto a otras cinco.

Elige k6 en lugar de Locust si tu equipo escribe JavaScript, quiere criterios de aprobado o suspenso como thresholds en el script, o necesita un modelo de carga abierto, que es lo que ofrecen los ejecutores arrival-rate de k6 (comprobado el 9 de octubre de 2026). LoadFocus ejecuta scripts de k6 desde 25 regiones en la nube, pero lanza los escenarios arrival-rate con un número fijo de usuarios; para sostener un ritmo de peticiones, ejecútalos con k6 directamente.

Elige JMeter en lugar de Locust si necesitas JDBC, JMS, LDAP o FTP de serie, como enumera su README, o si tus testers montan las pruebas en una interfaz gráfica. Locust vs JMeter compara ambas a fondo.

Elige Gatling en lugar de Locust si tu equipo trabaja sobre la JVM y quiere perfiles de inyección abiertos y cerrados en una misma API (comprobado el 9 de octubre de 2026). Gatling vs JMeter lo trata con más detalle.

FAQ

¿Locust es gratis para uso comercial? Sí. Locust se publica con licencia MIT, que permite el uso comercial, la modificación y la redistribución.

¿Qué versión de Python necesita Locust? Python 3.11 o posterior, según sus metadatos en PyPI. Instálalo con pip install locust, o ejecútalo en un entorno temporal con uvx locust.

¿LoadFocus puede ejecutar pruebas de Locust? No. LoadFocus ejecuta planes de prueba de JMeter y scripts de k6. Para escalar una prueba de Locust, usa su modo master y workers, el operador de Kubernetes o Azure Load Testing.

Lecturas relacionadas

Locust vs JMeter: ¿scripts de Python o planes de JMeter?

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Locust y Apache JMeter son dos herramientas de pruebas de carga gratuitas y open source, y cuál encaja mejor depende sobre todo de cómo quiere construir las pruebas tu equipo. Elige Locust si tu equipo escribe Python y quiere la lógica de prueba como código normal, ejecutada por usuarios ligeros basados en eventos. Elige JMeter si necesitas protocolos más allá de HTTP como JDBC, JMS o LDAP, prefieres montar las pruebas en una interfaz gráfica o ya tienes una colección de planes de prueba .jmx.

Los datos de esta comparación de Locust vs JMeter salen de la documentación y del repositorio de cada proyecto, comprobados el 9 de octubre de 2026.

	Locust	Apache JMeter
Licencia	MIT (repositorio)	Apache 2.0 (repositorio)
Entorno de ejecución	Python 3.11 o posterior	Java 8 o posterior (versión 5.6.3)
Pruebas escritas como	Código Python en un locustfile	Planes de prueba creados en una interfaz gráfica y guardados como XML (`.jmx`)
Interfaz gráfica	Interfaz web para lanzar, ajustar y seguir una prueba en marcha	IDE de escritorio para grabar, construir y depurar planes de prueba
Protocolos integrados	HTTP y HTTPS; el resto mediante un cliente Python	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, correo, TCP, comandos de shell, objetos Java
Usuarios virtuales	Un greenlet por usuario sobre gevent (basado en eventos)	Un hilo de Java por usuario
Modo distribuido	Un master y los workers que quieras	Un cliente que controla servidores JMeter remotos
CI y ejecución sin interfaz	`--headless`, código de salida 1 si fallan peticiones	Modo CLI (`jmeter -n`)
Informes	Gráficos en vivo en la interfaz web, archivos CSV, informe HTML	Panel HTML, resultados en vivo con un Backend Listener

¿Cuál es la diferencia entre Locust y JMeter?

En Locust una prueba es un programa en Python. En JMeter una prueba es un plan que montas en una interfaz gráfica de escritorio y guardas en un archivo, y de ahí salen casi todas las demás diferencias.

El README de Locust describe pruebas escritas con bucles, condiciones y bibliotecas de Python normales. Se instala con pip install locust y necesita Python 3.11 o posterior, según sus metadatos de paquete.

Una prueba de JMeter es un árbol de elementos: un Thread Group para los usuarios, samplers para las peticiones y assertions y listeners para los resultados. JMeter 5.6.3, la versión actual en la página de descargas, requiere Java 8 o posterior. El README de la rama de desarrollo de JMeter ya exige Java 17 (comprobado el 10 de octubre de 2026). Cuando un paso necesita lógica de verdad, un sampler JSR223 ejecuta un script de Groovy dentro del plan.

¿Cómo se escribe una prueba en cada herramienta?

En Locust escribes una clase de Python por cada tipo de usuario, con métodos marcados como tareas. En JMeter añades un Thread Group y samplers en la interfaz gráfica, guardas el plan y lo ejecutas desde la línea de comandos.

Un usuario de Locust que espera entre uno y tres segundos entre tareas y consulta la lista de usuarios tres veces más a menudo que la ficha de un usuario concreto:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def list_users(self):
        self.client.get("/api/users")

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Para lanzarlo sin interfaz con 50 usuarios, cinco nuevos por segundo, durante cinco minutos:

locust -f locustfile.py --headless -u 50 -r 5 \
  --run-time 5m --host https://staging.example.com

En JMeter la misma prueba es un Thread Group con 50 hilos y un periodo de rampa de subida, que contiene dos samplers HTTP Request. La guía de inicio ejecuta un plan guardado en modo CLI, y -e -o añade el informe HTML al final:

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

El archivo .jmx es XML, como muestran los ejemplos que incluye JMeter, y cuesta más revisarlo en un pull request que un archivo Python. JMeter también puede grabar un plan desde el navegador; lo más parecido en Locust es har2locust, un conversor de grabaciones HAR a locustfile que sigue en beta (comprobado el 9 de octubre de 2026).

¿Qué protocolos puede probar cada herramienta?

JMeter cubre muchos más protocolos de serie. Locust trae HTTP y HTTPS y espera que aportes un cliente Python para todo lo demás.

El README de JMeter enumera HTTP y HTTPS, SOAP y REST, FTP, bases de datos mediante JDBC, LDAP, mensajería JMS, correo por SMTP, POP3 e IMAP, TCP, comandos nativos y objetos Java. JDBC y JMS necesitan los JAR del controlador que proporciona tu proveedor de base de datos o de JMS.

La página sobre otros protocolos de la documentación de Locust muestra cómo envolver una biblioteca de protocolo, con ejemplos para gRPC, XML-RPC y MQTT, y remite a locust-plugins para Kafka, Selenium y Playwright (comprobado el 9 de octubre de 2026). La biblioteca tiene que funcionar con gevent, porque la E/S hecha en código C compilado bloquea todo el proceso; la documentación cita el controlador de PostgreSQL psycopg2, que necesita un paquete adicional. Para pruebas de carga contra bases de datos, el sampler JDBC de JMeter es el camino más corto.

¿Cómo funcionan los usuarios virtuales en Locust y JMeter?

JMeter ejecuta cada usuario virtual como un hilo de Java. Locust ejecuta cada usuario como un greenlet en el bucle de eventos de gevent, lo que mantiene bajo el coste de cada usuario.

Cada hilo de un Thread Group de JMeter recorre el plan completo de forma independiente. JMeter arranca por defecto con un heap de 1 GB, que según su guía puede quedarse corto en planes grandes y con muchos hilos.

Según su README, un solo proceso de Locust puede manejar muchos miles de usuarios concurrentes. La documentación de carga distribuida añade que un proceso de Python no puede aprovechar del todo más de un núcleo de CPU, así que se lanza un worker por núcleo, algo que --processes prepara por ti en una sola máquina.

¿Cómo se reparte una prueba entre varias máquinas?

Las dos tienen un modo distribuido integrado. En Locust un master dirige a los workers que ejecutan los usuarios, y en JMeter el cliente lanza el plan de prueba completo en cada servidor remoto.

En Locust, un proceso iniciado con --master ejecuta la interfaz web y les indica a los procesos --worker cuándo arrancar y detener usuarios. La documentación de Locust también cubre un operador de Kubernetes y Azure Load Testing, un servicio de Microsoft que ejecuta pruebas de Locust en la nube (comprobado el 9 de octubre de 2026).

El modo de pruebas remotas de JMeter permite que un cliente controle tantos servidores como quieras mediante RMI. Cada servidor ejecuta el plan completo, así que 1.000 hilos en seis servidores son 6.000 hilos. Todos los nodos deberían usar la misma versión de JMeter y de Java, RMI necesita un keystore salvo que desactives SSL, y los archivos de datos hay que copiarlos a cada servidor.

Hay una tercera vía para los planes de prueba de JMeter. LoadFocus, el editor de este sitio, ejecuta tus planes de prueba de JMeter existentes sin cambios desde 25 regiones en la nube, sin servidores remotos que configurar. LoadFocus no ejecuta pruebas de Locust, así que para Locust siguen valiendo las opciones de arriba para escalar.

¿Cómo encajan en la CI y qué informes obtienes?

Las dos se ejecutan sin interfaz desde la línea de comandos. Locust además termina con el código de salida 1 cuando fallan peticiones, y JMeter genera el informe HTML más completo.

La documentación del modo headless de Locust muestra un listener de eventos corto que fija el código de salida según la tasa de fallos, el tiempo de respuesta medio o el percentil 95, además de un ejemplo para GitHub Actions. Las opciones --csv y --html guardan los resultados y un informe al terminar.

La documentación de JMeter es tajante: las pruebas de carga se ejecutan en modo CLI y la interfaz gráfica queda para construir y depurar. Su README remite a bibliotecas de terceros para Maven, Gradle y Jenkins. El panel de JMeter incluye una tabla APDEX, una tabla de estadísticas con tres percentiles configurables, resúmenes de errores y gráficos del tiempo de respuesta.

¿Cuál deberías elegir?

Elige Locust si tu equipo escribe Python y quiere revisar las pruebas de carga como el resto de su código. Elige JMeter en su lugar si necesitas protocolos más allá de HTTP, si tus testers prefieren una interfaz gráfica o si ya tienes planes .jmx.

Locust encaja con escenarios que tienen bucles, ramificaciones y datos generados, con pruebas que reutilizan un cliente Python interno de tu API y con mucha concurrencia de usuarios que pasan la mayor parte del tiempo esperando.

JMeter es la mejor opción para probar JDBC, JMS, LDAP, FTP o correo, donde Locust necesitaría un cliente que tendrías que mantener tú, y para testers que graban un recorrido en el navegador y lo afinan de forma visual. Una empresa que ya usa JMeter conserva además sus planes y su experiencia.

FAQ

¿Locust es más rápido que JMeter? No lo hemos medido nosotros, así que no nombramos un ganador. La comparación justa es ejecutar el mismo escenario con las dos herramientas en tu propio hardware.

¿Locust puede ejecutar archivos .jmx de JMeter? No según su documentación, que describe las pruebas solo como locustfiles de Python. Pasar un plan de prueba de JMeter a Locust significa reescribirlo en Python.

¿LoadFocus puede ejecutar pruebas de Locust? No. LoadFocus ejecuta scripts de JMeter y k6. Para escalar una prueba de Locust más allá de una máquina, usa el modo master y workers de Locust, su operador de Kubernetes o Azure Load Testing.

Lecturas relacionadas

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

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

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.

	Modelo abierto	Modelo cerrado
Lo que fijas	Nuevas iteraciones o usuarios por segundo	Usuarios virtuales concurrentes
Cuando las respuestas se ralentizan	El trabajo sigue llegando y las colas crecen	Los usuarios esperan y se envía menos carga
Sistemas reales así	La mayoría de sitios web y API públicos	Centros de llamadas, colas de venta de entradas, pools de workers
k6	`constant-arrival-rate`, `ramping-arrival-rate`	`constant-vus`, `ramping-vus`
Gatling	`injectOpen`	`injectClosed`
Locust	Aproximado con `constant_throughput` o `poisson`	Usuarios con un `wait_time`
JMeter	Open Model Thread Group, plugin Arrivals	Thread Group

¿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

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

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

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.

Tiempo de reflexión por vuelta	Una vuelta dura	Peticiones por segundo con 100 usuarios
0 s	0,5 s	200
1 s	1,5 s	unas 67
3 s	3,5 s	unas 29
5 s	5,5 s	unas 18
10 s	10,5 s	unas 10

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.

Herramienta	Pausa fija	Pausa aleatoria	Pacing o ritmo
k6	`sleep(3)`	`sleep(2 + Math.random() * 6)`	Ejecutores por tasa de llegada
JMeter	Constant Timer	Uniform o Gaussian Random Timer	Constant Throughput Timer
Gatling	`pause(3)`	`pause(2, 8)`	`pace(30)`
Locust	`constant(3)`	`between(2, 8)`	`constant_pacing`
Artillery	`think: 3`	`think` + `jitter` (en `config.http.defaults`)	Tasa de llegada por fase

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

Herramientas de pruebas de carga WebSocket: seis opciones

Fri, 09 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Entre las herramientas de pruebas de carga WebSocket, k6, Artillery, Gatling y Tsung soportan el protocolo de serie, mientras que JMeter necesita el plugin WebSocket Samplers y Locust, código cliente que escribas tú o su usuario experimental de Socket.IO. Elige según el lenguaje en el que escribe tu equipo y, después, según lo estrictamente que debas comprobar los mensajes que devuelve el servidor.

Para este artículo no hemos ejecutado estas herramientas contra un servidor WebSocket. Los datos salen de la documentación y el repositorio de cada proyecto, comprobados el 9 de octubre de 2026, y las notas de «Opta por» son nuestra opinión.

Herramienta	Soporte de WebSocket	Pruebas escritas en	Comprobar lo que envía el servidor
k6	De serie: `k6/websockets`, el antiguo `k6/ws`	JavaScript	Manejadores de eventos en tu script
Artillery	Motores de serie `ws` y `socketio`	YAML, más funciones de JavaScript	Respuestas y acuses de recibo de Socket.IO
Gatling	Parte del SDK de HTTP	Java, Kotlin, Scala, JavaScript	Checks que esperan un mensaje concreto
Apache JMeter	Plugin WebSocket Samplers	Planes de prueba creados en la interfaz gráfica	Samplers de request-response y de lectura
Locust	Tu propio cliente, o el `SocketIOUser` experimental	Python	Lo que informe tu código
Tsung	Tipo de sesión de serie `ts_websocket`	XML	`ack` espera una respuesta del servidor

¿En qué se diferencia la carga WebSocket de la carga HTTP?

Un usuario WebSocket abre una conexión y la mantiene durante toda la sesión, y el servidor puede enviar mensajes cuando quiera. Por eso una prueba tiene dos palancas, las conexiones abiertas y los mensajes por segundo, y cada una carga el servidor a su manera.

La guía de WebSocket de k6 describe tráfico full-duplex sobre una sola conexión TCP y explica que un usuario virtual deja de repetir la función principal y ejecuta un bucle de eventos mientras el socket sigue abierto. La referencia de WebSocket de Gatling añade que el tráfico va en los dos sentidos, así que el modelo de petición y respuesta de HTTP ya no encaja.

Planifica tres tipos de prueba. Muchas conexiones inactivas muestran cuántos sockets pueden mantener tus servidores. Un grupo menor de clientes que hablan mucho pone a prueba el manejo de mensajes. Una difusión, en la que un mensaje llega a todos los suscriptores, pone a prueba el envío de mensajes push.

¿Qué deberías medir en una prueba de carga WebSocket?

Mide el tiempo de conexión, la latencia de los mensajes y las conexiones caídas, además de cuántas conexiones siguen abiertas. Son los valores que notan los usuarios de una aplicación en tiempo real.

Las métricas integradas de k6 incluyen ws_connecting, ws_ping, ws_session_duration, ws_sessions y contadores de mensajes. Ninguna cronometra un mensaje de la aplicación, así que el tiempo entre el mensaje de un cliente y la respuesta del servidor necesita una métrica Trend propia. El motor ws de Artillery informa del número y el ritmo de mensajes, y su motor de Socket.IO añade socketio.response_time, desde que se emite un mensaje hasta que llega la respuesta.

Para las conexiones caídas, cuenta los eventos close y error que tu script no haya provocado, y compara las sesiones iniciadas con las que siguen abiertas al final de cada etapa.

¿Cuándo es k6 la herramienta WebSocket adecuada?

Cuando tu equipo escribe JavaScript y cada usuario virtual debe mantener varios sockets a la vez. k6 trae soporte de WebSocket de serie, sin extensiones que instalar.

El módulo k6/websockets sigue la API WebSocket del navegador y usa un bucle de eventos global, que permite a un usuario virtual mantener varias conexiones abiertas. El módulo antiguo k6/ws sigue documentado, pero k6 recomienda k6/websockets para pruebas nuevas, y k6/experimental/websockets está obsoleto.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Los thresholds también funcionan con métricas propias, así que un objetivo de latencia incumplido le da a la CI un código de salida distinto de cero. Opta por Artillery cuando tu servidor hable Socket.IO y quieras comprobar emisiones y acuses de recibo sin escribir código cliente. Nuestra comparativa k6 vs Artillery cubre el resto de diferencias.

¿Cuándo encaja Artillery?

Cuando quieres escenarios YAML cortos, o cuando tu servidor usa Socket.IO. Los dos motores vienen con el propio Artillery.

Un escenario con el motor de WebSocket se construye con cinco acciones: connect, send, think, loop y function. El motor de Socket.IO va más allá: un emit puede declarar la respuesta que espera, validar un acuse de recibo con una coincidencia JSONPath y compartir escenario con peticiones HTTP, algo útil para aplicaciones que inician sesión por HTTP antes de abrir un socket.

Opta por k6 o Gatling cuando una prueba deba comprobar lo que devuelve un servidor WebSocket puro, porque la documentación del motor ws no describe ningún paso que espere o compare una respuesta.

¿Para quién es Gatling en WebSockets?

Para equipos en la JVM, o en el SDK de JavaScript de Gatling, que quieren escribir las comprobaciones de mensajes dentro del escenario. El soporte de WebSocket forma parte del SDK de HTTP de Gatling, así que los pasos HTTP y WebSocket comparten una misma simulación.

La referencia cubre connect, sendText, sendBytes y close, además de checks que bloquean hasta que llega el mensaje esperado o vence un tiempo límite. Los ajustes del protocolo permiten reconectar un socket que cerró el servidor, responder automáticamente a ciertos mensajes de texto como un ping y guardar en un búfer los mensajes que ningún check reconoció. Según su repositorio, WebSocket forma parte de la Community Edition con licencia Apache 2.0, sin límites.

Opta por k6 si prefieres reaccionar a los mensajes que empuja el servidor con manejadores de eventos en lugar de checks bloqueantes.

¿Puede JMeter hacer pruebas de carga de WebSockets?

Sí, con un plugin. JMeter no tiene sampler de WebSocket, y la extensión habitual es WebSocket Samplers de Peter Doornbosch.

La referencia de componentes de JMeter no menciona WebSocket en ningún momento. El repositorio del plugin describe seis samplers: abrir conexión, request-response, ping-pong, lectura única, escritura única y cierre. Se ejecutan en el propio hilo del Thread Group, soportan wss y tramas binarias, y pueden filtrar las tramas que no interesan a la prueba. Se instala con el Plugins Manager o copiando su jar en lib/ext, y la versión 1.3.2 se etiquetó en enero de 2026 (comprobado el 9 de octubre de 2026).

Elige otra herramienta si prefieres no mantener un plugin de terceros en cada generador de carga.

¿Y Locust y Tsung?

Locust solo llega a los WebSockets puros con código cliente que añades tú, y Tsung los soporta en su configuración XML, aunque publica versiones nuevas muy de vez en cuando. Los dos funcionan, con más esfuerzo.

Según la documentación de Locust, la herramienta solo soporta de serie HTTP y HTTPS; los demás protocolos se añaden envolviendo una biblioteca cliente y lanzando un evento request después de cada llamada. La biblioteca tiene que poder parchearse con gevent, o bloqueará todo el proceso. Para Socket.IO existe un SocketIOUser experimental. Elige Locust si tu equipo escribe Python y no le importa mantener ese código cliente.

Tsung es un proyecto en Erlang que se describe como una herramienta de pruebas de carga distribuida y multiprotocolo. Su documentación de sesiones define para WebSocket las peticiones connect, message y close, con un atributo ack para esperar una respuesta. Su última versión etiquetada, la 1.8.0, es de marzo de 2023.

¿Dónde encaja un servicio alojado como LoadFocus?

Mantener muchos sockets abiertos desde tus propias máquinas da trabajo, y un servicio alojado se encarga de generar la carga. Encaja mejor cuando tus pruebas ya son scripts de k6.

LoadFocus, el editor de este sitio, ejecuta scripts de k6 desde 25 regiones en la nube, y su página de k6 incluye las conexiones WebSocket entre las funciones de k6 que soporta. También ofrece una plantilla de prueba WebSocket con rampa de subida y bajada (en inglés). No hemos comprobado si ejecuta plugins de JMeter como WebSocket Samplers, así que no afirmamos nada al respecto.

¿Cómo elegir entre ellas?

Parte del lenguaje de tu equipo y pregúntate después si pruebas WebSockets puros o Socket.IO y con qué rigor debes comprobar los mensajes que empuja el servidor. Normalmente quedan una o dos candidatas.

Escribe en las dos la misma prueba corta de conectar, enviar y recibir, y compara el tiempo de conexión y la latencia de los mensajes con poca carga. Nuestra guía Cómo hacer una prueba de carga recorre los pasos, y el repaso de herramientas de pruebas de carga open source compara estos proyectos más allá de WebSocket.

FAQ

¿Con qué herramienta de pruebas de carga WebSocket debería empezar? Si tu equipo escribe JavaScript, empieza por k6, que trae WebSocket de serie. Para aplicaciones con Socket.IO, el motor de Artillery pide menos código, y los equipos de la JVM se sentirán como en casa con Gatling.

¿Puede JMeter probar WebSockets sin un plugin? Su referencia de componentes no incluye ningún sampler de WebSocket, así que el camino práctico es el plugin WebSocket Samplers, instalado con el Plugins Manager o como jar en lib/ext.

¿Debería usar k6/ws o k6/websockets? Usa k6/websockets para pruebas nuevas, como recomienda la documentación de k6. El módulo antiguo k6/ws sigue documentado para los scripts existentes.

Lecturas relacionadas

Cómo hacer una prueba de carga: guía paso a paso

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, un servicio de pruebas de carga mencionado en este artículo.

Para hacer una prueba de carga, decide qué es un buen resultado, programa un recorrido de usuario realista, comprueba ese script con un solo usuario y después sube la carga por escalones mientras vigilas los tiempos de respuesta y los errores. Compara lo que mediste con el objetivo que fijaste al principio y cambia una sola cosa antes de la siguiente ejecución.

Paso	Qué haces	Terminado cuando
1. Fijar el objetivo	Elegir la carga a probar y las cifras que cuentan como éxito	Puedes escribir los criterios en una frase
2. Programar un recorrido	Convertir un recorrido real de usuario en un script	El script se ejecuta sin errores
3. Prueba de humo	Ejecutarlo con un usuario virtual	Todas las comprobaciones pasan
4. Subir la carga	Aumentar la carga por escalones y mantener el objetivo	Llegas al objetivo o a una condición de parada
5. Leer los resultados	Comparar percentiles y errores con el objetivo	Sabes si pasó y qué cambiar

¿Qué debes decidir antes de hacer una prueba de carga?

Decide para qué carga pruebas y qué resultado cuenta como éxito. Sin las dos cosas, una prueba de carga produce números, pero no una respuesta.

Parte del tráfico real si lo tienes. Tu analítica o tus logs de acceso te dicen cuál es la hora de más tráfico, cuántas peticiones por segundo llegan y qué páginas o endpoints se llevan la mayoría. Pon el objetivo por encima de ese pico, porque la idea es saber que tienes margen. Después escribe los criterios como números, por ejemplo: el percentil 95 del tiempo de respuesta se mantiene por debajo de 500 ms y fallan menos del 1 % de las peticiones con 200 usuarios virtuales.

Aquí también entran dos decisiones prácticas. Elige un entorno parecido a producción en tamaño y configuración, porque un servidor de staging con una cuarta parte de la capacidad dice poco sobre producción. Y asegúrate de tener permiso para probarlo: lanzar una prueba de carga contra un sistema que no es tuyo, o que compartes con otros equipos, sin avisar se parece exactamente a un ataque.

¿Cómo se programa un recorrido de usuario realista?

Programa el recorrido que más importa al negocio, paso a paso, con pausas donde una persona real leería o escribiría. Un script que llama a una sola URL lo más rápido posible mide algo, pero rara vez lo que te interesa.

En una tienda podría ser: abrir la portada, buscar, abrir un producto, añadirlo al carrito. En una API: iniciar sesión, listar elementos, obtener uno. Añade una pausa corta entre pasos (tiempo de reflexión), usa datos de prueba variados para que las cachés se comporten como en la vida real y comprueba cada respuesta para que una página de error no pase por una respuesta rápida.

Este es el script que usamos para el ejemplo de esta guía, escrito para k6. Sube a 10 usuarios virtuales, mantiene la carga y baja, con dos criterios de éxito incluidos:

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

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Un recorrido real tiene varias peticiones y URLs reales. Este es diminuto a propósito, para que los pasos sean fáciles de seguir.

¿Por qué hacer primero una prueba de humo con un solo usuario?

Una prueba de humo con un usuario virtual demuestra que el script funciona antes de poner carga real sobre nada. Es la forma más barata de detectar una URL equivocada, un token de inicio de sesión que falta o una comprobación que siempre falla.

Con k6 puedes sobrescribir la carga desde la línea de comandos, así que el mismo script se ejecuta una vez con un solo usuario:

k6 run --vus 1 --iterations 1 script.js

En nuestra ejecución, la única comprobación pasó, así que el script estaba listo para la carga. Si aquí falla una comprobación, arregla el script antes de seguir: los errores con un usuario se convierten en ruido con cien.

¿Cómo se debe subir la carga?

Sube la carga por escalones y mantén cada escalón el tiempo suficiente para que se estabilice, en lugar de saltar directamente al objetivo. Una rampa por escalones te muestra a partir de qué nivel empiezan a empeorar las cosas.

Una forma habitual es subir a un primer escalón, mantenerlo unos minutos, subir al siguiente, mantenerlo otra vez y así hasta el objetivo, y después bajar. Si miras cada tramo por separado, ves si los tiempos de respuesta suben de forma gradual con la carga o se mantienen planos y luego saltan. Ese salto, el punto en el que cada usuario extra hace más lenta cada petición, es lo más útil que puede encontrar una prueba de carga. Nuestro ejemplo solo sube a 10 usuarios y mantiene 20 segundos, suficiente para mostrar los escalones pero demasiado corto para una prueba real.

¿Qué hay que vigilar mientras corre la prueba?

Vigila los percentiles del tiempo de respuesta, la tasa de errores y el rendimiento en el lado del generador de carga, y la CPU, la memoria y la carga de la base de datos en el sistema que pruebas. Las tres primeras cosas te dicen cómo lo notarían los usuarios, y las tres últimas, por qué.

Acuerda condiciones de parada antes de empezar, por ejemplo: parar si la tasa de errores pasa del 5 % o si los tiempos de respuesta llegan a varios segundos. Seguir empujando un sistema que ya se ha caído no enseña nada, y en un entorno compartido estorba el trabajo de otros.

Vigila también el generador de carga. Si está al 100 % de CPU, las respuestas lentas pueden venir de tu propio portátil y no del servidor.

¿Cómo se leen los resultados de una prueba de carga?

Lee los percentiles y la tasa de errores frente a los criterios que anotaste al principio. El tiempo de respuesta medio es la cifra menos útil del informe.

Esto es lo que dio nuestra ejecución de ejemplo (35 segundos, hasta 10 usuarios virtuales, una pequeña página estática servida en un portátil, el 8 de octubre de 2026):

Métrica	Valor
Peticiones	282 (8 por segundo)
Peticiones fallidas	0 %
Tiempo de respuesta medio	0,69 ms
Percentil 90	0,66 ms
Percentil 95	0,71 ms
Percentil 99	2,68 ms
Petición más lenta	15,98 ms
Thresholds	Los dos superados

Las cifras son diminutas porque el objetivo era un archivo estático en la misma máquina, así que no sirven como benchmark. La lección está en la forma: la media quedó por encima del percentil 90, porque un puñado de peticiones lentas la arrastró hacia arriba. Los percentiles describen lo que vivió la mayoría de las peticiones, y el percentil 99 y la petición más lenta muestran la cola que sufren unos pocos usuarios. Juzga la ejecución por el percentil de tus criterios y usa la cola para decidir si algo merece una mirada más atenta.

Si una ejecución no cumple su objetivo, cambia una sola cosa (una consulta, un ajuste de caché, un tamaño de instancia) y vuelve a lanzar la misma prueba, para saber qué marcó la diferencia.

¿Cuándo conviene lanzar la prueba desde la nube?

Lleva el generador de carga a la nube cuando una máquina no puede producir la carga que necesitas, o cuando importa dónde están tus usuarios. Un portátil en el Wi-Fi de la oficina mide tu conexión tanto como tu servidor.

El mismo script de k6 puede ejecutarse en infraestructura que gestionas tú, en el servicio alojado de Grafana o en LoadFocus, que ejecuta scripts de k6 desde 25 regiones en la nube. Sus informes desglosan los resultados por ubicación y muestran el tiempo de respuesta frente al número de usuarios virtuales, que es donde se ve el salto descrito arriba (cómo leer los resultados en LoadFocus).

FAQ

¿Cuánto debe durar una prueba de carga? Lo suficiente para mantener la carga objetivo varios minutos después de la subida, de modo que los picos cortos no decidan el resultado. Mantener al menos 10 minutos es un buen punto de partida, y bastante más si buscas fugas de memoria o una degradación lenta.

¿Cuántos usuarios virtuales necesito? Calcúlalo a partir del tráfico real. Toma las peticiones por segundo de la hora de más tráfico, estima cuántas peticiones hace un recorrido y cuánto dura, y dimensiona los usuarios virtuales para que la prueba produzca ese ritmo con algo de margen.

¿Es seguro hacer pruebas de carga en producción? Puede serlo, con cuidado: prueba en un momento tranquilo, avisa a quien opera el sistema, fija condiciones de parada y empieza muy por debajo del pico esperado. Muchos equipos prefieren un entorno de staging del tamaño de producción, para que una prueba fallida no afecte a ningún cliente.

Lecturas relacionadas

k6 vs Artillery: qué herramienta de pruebas de carga elegir

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

k6 y Artillery son herramientas de pruebas de carga open source en las que las pruebas se escriben como código, y cualquiera de las dos prueba bien una API HTTP bajo carga. Elige k6 si quieres un único binario, la lógica de prueba en JavaScript y umbrales de éxito integrados. Elige Artillery si tu equipo ya trabaja en Node.js, prefiere escenarios cortos en YAML o necesita pruebas de navegador con Playwright y ejecuciones distribuidas en AWS o Azure desde la línea de comandos.

Los datos de abajo salen de la documentación y del repositorio de cada proyecto, comprobados el 8 de octubre de 2026.

	k6	Artillery
Licencia	AGPL-3.0 (repositorio)	MPL-2.0, algunos módulos de Azure con BSL (repositorio)
Entorno de ejecución	Un binario de Go con un motor de JavaScript integrado	Node.js, última versión LTS
Scripts de prueba	JavaScript	YAML, TypeScript o JavaScript
Protocolos principales	HTTP, WebSockets, gRPC	HTTP, WebSocket, Socket.IO (gRPC y Kinesis con motores adicionales)
Pruebas de navegador	Módulo de navegador integrado	Playwright
Criterios de éxito	Thresholds	Plugin `ensure`
Ejecución distribuida	k6-operator en Kubernetes, o Grafana Cloud k6	`run-lambda` o `run-fargate` en AWS, `run-aci` en Azure

¿Cuál es la diferencia entre k6 y Artillery?

Se diferencian sobre todo en el entorno de ejecución y en cómo describes la carga. k6 es una herramienta compilada en Go que ejecuta código de prueba en JavaScript, mientras que Artillery es una herramienta de Node.js que lee escenarios en YAML o JavaScript.

Esa diferencia se nota desde el primer día. Instalar k6 es instalar un paquete o un binario independiente, sin un entorno de ejecución que mantener. Artillery necesita Node.js y se instala con npm, algo natural en un proyecto de JavaScript y un entorno más que mantener al día en cualquier otro sitio.

En protocolos, lo que comparten cubre casi todo el trabajo web: ambos hablan HTTP y WebSockets de serie. k6 trae además gRPC, y Artillery, Socket.IO. Artillery consigue gRPC y Kinesis con motores adicionales que se instalan aparte (comprobado el 9 de octubre de 2026), y k6 llega más lejos con su ecosistema de extensiones.

¿Cómo se escribe una prueba en cada herramienta?

En k6 escribes un módulo de JavaScript con las opciones arriba y una función por defecto que ejecuta cada usuario virtual. En Artillery sueles escribir un archivo YAML con un bloque config para la carga y un bloque scenarios para lo que hace cada usuario virtual.

Una prueba de k6 que sube a 20 usuarios virtuales y falla si el percentil 95 del tiempo de respuesta pasa de 500 ms:

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

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m", target: 20 },
    { duration: "15s", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<500"] },
};

export default function () {
  const res = http.get("https://staging.example.com/api/users");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

La misma idea en el formato YAML de Artillery, con diez usuarios virtuales nuevos por segundo durante un minuto:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Los dos ejemplos modelan la carga de forma distinta. El script de k6 fija un número de usuarios virtuales simultáneos, y el archivo de Artillery fija cuántos usuarios virtuales nuevos llegan cada segundo. k6 también puede controlar tasas de llegada con sus executors de escenarios, y Artillery puede limitar la concurrencia con maxVusers, así que elige el modelo que se parezca a cómo llega el tráfico real a tu sistema, no el que cada herramienta muestra primero.

¿Cómo deciden k6 y Artillery si una prueba ha pasado?

Las dos convierten un objetivo de rendimiento en un código de salida, que es lo que necesita un pipeline de CI. Un objetivo incumplido termina la ejecución con un código de salida distinto de cero en las dos herramientas.

En k6 los objetivos son thresholds y van en las opciones del script, como en el ejemplo de arriba. En Artillery viven en el plugin ensure, que admite umbrales simples y condiciones que combinan varias métricas.

La diferencia práctica está en dónde viven los objetivos. Los thresholds de k6 están en el mismo archivo que la lógica de la prueba. Las comprobaciones de Artillery están en el bloque config, donde puede ajustarlas alguien que nunca toca los escenarios.

¿Cómo se ejecuta una prueba más grande de lo que puede generar una máquina?

Las dos herramientas pueden repartir una prueba entre muchas máquinas, por caminos muy distintos. k6 se apoya en Kubernetes o en el servicio alojado de Grafana, y Artillery en tu propia cuenta de AWS o Azure.

Para k6, el k6-operator reparte una prueba entre pods de un clúster de Kubernetes, y Grafana Cloud k6 ejecuta los mismos scripts como servicio alojado. Para Artillery, los comandos run-lambda y run-fargate lanzan workers en tu cuenta de AWS tras una configuración IAM única con una pila de CloudFormation. En Azure, run-aci hace lo mismo con Azure Container Instances, pero exige una suscripción de pago a Artillery para algo más que una evaluación (comprobado el 9 de octubre de 2026). Si ya usas Kubernetes, el camino del operator te resultará familiar. Si prefieres no operar nada, el camino serverless de Artillery tiene menos piezas móviles, siempre que la prueba pueda vivir en AWS o Azure.

Hay un tercer camino para los scripts de k6. LoadFocus ejecuta scripts de k6 en su propia infraestructura en la nube desde 25 regiones, así que el script que lanzas en tu portátil se convierte en una prueba distribuida sin clúster ni cuenta de AWS. LoadFocus no ejecuta scripts de Artillery, de modo que para Artillery sus propios comandos de AWS y Azure siguen siendo la forma de escalar.

¿Adónde van los resultados?

Las dos herramientas muestran un resumen al final de cada ejecución y pueden enviar métricas a otros sistemas para paneles y alertas.

Según su repositorio, k6 ofrece estadísticas resumidas o métricas detalladas exportadas al servicio que elijas. Artillery enumera en su repositorio más de 20 integraciones de monitorización, observabilidad y CI/CD. Las dos pueden alimentar los paneles que ya tienes. Antes de decidirte, comprueba que la salida concreta que necesitas está en la lista, porque ambas listas cambian entre versiones.

¿Cuál deberías elegir?

Elige k6 si quieres un único binario en la CI, lógica de prueba en JavaScript con control de flujo real y thresholds en el mismo archivo que la prueba. También encaja con equipos que ya usan Grafana, porque la herramienta open source y el servicio alojado comparten la misma API de scripts.

Elige Artillery si tu equipo escribe Node.js a diario, si un archivo YAML corto es más fácil de revisar para el resto del equipo que un script, o si necesitas pruebas de navegador con Playwright y Socket.IO en la misma herramienta. Su escalado serverless también es el camino más corto si tu infraestructura ya vive en AWS y Kubernetes no forma parte de ella.

Si aún dudas, escribe la misma prueba de humo en las dos. Veinte líneas bastan para ver cuál le resulta más fácil de leer a tu equipo en una revisión de código.

FAQ

¿k6 es gratis? Sí. k6 es open source con licencia AGPL-3.0 y funciona gratis en tus propias máquinas. Grafana Cloud k6 es un servicio alojado aparte, con sus propios precios.

¿Artillery es gratis? En su mayor parte. Casi todo Artillery tiene licencia MPL-2.0, pero algunos módulos específicos de Azure usan una licencia source-available que exige una licencia comercial para uso en producción en Azure, según el repositorio del proyecto (comprobado el 8 de octubre de 2026).

¿LoadFocus puede ejecutar pruebas de Artillery? No. LoadFocus ejecuta scripts de k6 y JMeter. Para escalar una prueba de Artillery más allá de una máquina, usa los comandos de Artillery para AWS Lambda, Fargate o Azure Container Instances en tu propia cuenta en la nube.

¿Qué herramienta consume menos recursos en el generador de carga? No lo hemos medido nosotros, así que no nombramos un ganador. El proyecto k6 dice que incluso máquinas modestas pueden simular mucho tráfico, y la comparación justa es ejecutar el mismo escenario con las dos herramientas en tu propio hardware.

Lecturas relacionadas

Herramientas de pruebas de carga open source: seis opciones

Thu, 08 Oct 2026 00:00:00 GMT

Aviso: loadtest.app lo publica LoadFocus, que vende un servicio de pruebas de carga que aparece en este artículo.

Seis herramientas de pruebas de carga open source muy usadas hoy son Apache JMeter, k6, Gatling, Locust, Artillery y Vegeta. Elige según el lenguaje en el que tu equipo escribe las pruebas y según cómo necesites escalar: JMeter para la mayor cobertura de protocolos, k6 o Artillery para JavaScript, Gatling para la JVM, Locust para Python y Vegeta para comprobaciones HTTP rápidas a ritmo fijo.

Para este artículo no hemos comparado estas herramientas entre sí con benchmarks. Los datos salen del repositorio y la documentación de cada proyecto, comprobados el 8 de octubre de 2026, y las notas de «Ideal para» son nuestra opinión.

Herramienta	Licencia	Pruebas escritas en	Se ejecuta en	Repartir la carga entre máquinas
Apache JMeter	Apache 2.0	Planes de prueba creados en una interfaz gráfica	Java	Modo remoto (cliente-servidor) integrado
k6	AGPL-3.0	JavaScript	Un binario de Go	k6-operator en Kubernetes
Gatling	Apache 2.0 (algunos componentes con licencia enterprise)	Java, Kotlin, Scala, JavaScript, TypeScript	JVM	Edición Enterprise comercial
Locust	MIT	Python	Python	Integrado
Artillery	MPL-2.0 (algunos módulos de Azure con BSL)	YAML, JavaScript, TypeScript	Node.js	AWS Lambda, Fargate o Azure ACI desde la CLI
Vegeta	MIT	Línea de comandos o código Go	Un binario de Go	Lanzar varias instancias

¿Sigue mereciendo la pena Apache JMeter?

Sí, sobre todo si necesitas protocolos más allá de HTTP. JMeter cubre el abanico más amplio de las seis y tiene detrás el mayor volumen de planes de prueba y conocimiento.

JMeter es una aplicación Java con licencia Apache 2.0. Su lista de protocolos incluye HTTP y HTTPS, servicios web SOAP y REST, FTP, bases de datos mediante JDBC, LDAP, mensajería JMS, correo y TCP sin más. Los planes de prueba se crean en una interfaz gráfica de escritorio, las pruebas reales se lanzan sin interfaz desde la línea de comandos y el modo remoto cliente-servidor reparte una prueba entre varias máquinas.

Ideal para sistemas con varios protocolos, equipos que ya tienen planes de JMeter y testers que prefieren construir las pruebas de forma visual. Elige otra cosa si tu equipo quiere pruebas como código puro, revisadas igual que la aplicación, porque los planes XML creados en una interfaz gráfica son difíciles de leer en una pull request.

¿Cuándo es k6 la opción adecuada?

Cuando tu equipo escribe JavaScript y quiere pruebas en código con umbrales de éxito integrados. Se distribuye como un único binario de Go, lo que simplifica su configuración en la CI.

k6 tiene licencia AGPL-3.0 y habla HTTP, WebSockets y gRPC, con un módulo de navegador para comprobaciones de front-end. Los thresholds convierten un objetivo, como un límite al percentil 95, en un código de salida distinto de cero para la CI. Para escalar, el k6-operator ejecuta pruebas distribuidas en Kubernetes, y Grafana vende un servicio alojado.

Ideal para desarrolladores que mantienen sus pruebas de API junto al código y para pipelines de CI. Elige otra cosa si tu equipo no quiere JavaScript o si la licencia AGPL no encaja con cómo integras o distribuyes la herramienta. La comparamos a fondo en k6 vs Artillery.

¿Para quién es Gatling?

Para equipos en la JVM que quieren pruebas como código y un informe HTML detallado sin añadir nada. También ofrece un SDK de JavaScript y TypeScript sobre el mismo motor.

Gatling ejecuta los usuarios virtuales sobre un motor no bloqueante construido con Netty, así que una sola máquina puede generar mucha carga. Las simulaciones se escriben en Java, Kotlin, Scala, JavaScript o TypeScript y se ejecutan con plugins de Maven, Gradle, sbt o npm. La edición comunitaria tiene licencia Apache 2.0 y cubre HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events y JMS, mientras que sus componentes de gRPC, MQTT y GraphQL usan la licencia enterprise de Gatling.

Ideal para equipos de Java y Scala, y para quien quiera informes completos sin herramientas extra. Elige otra cosa si necesitas repartir la carga entre máquinas solo con la edición open source: generar carga desde infraestructura gestionada o privada es la función de Gatling Enterprise, la edición comercial.

¿Es Locust una buena opción para equipos de Python?

Sí. Las pruebas de Locust son Python puro, así que bucles, condiciones y cualquier biblioteca de Python funcionan como en código normal.

Locust tiene licencia MIT y funciona por eventos con gevent, lo que permite a un solo proceso atender a muchos usuarios. Las pruebas se lanzan desde la línea de comandos o desde una interfaz web que muestra en directo el rendimiento, los tiempos de respuesta y los errores, y Locust reparte una prueba entre varias máquinas por sí mismo. HTTP viene integrado y otros protocolos se añaden escribiendo Python.

Ideal para equipos de Python, escenarios con lógica compleja y quien disfrute siguiendo una prueba en el navegador. Elige otra cosa si quieres pruebas declarativas al estilo de un archivo de configuración, o si un plugin listo para un protocolo poco común importa más que escribir uno propio.

¿Cuándo tiene sentido Artillery?

Cuando tu equipo vive en Node.js, le gustan los escenarios cortos en YAML o quiere pruebas de navegador con Playwright en la misma herramienta que sus pruebas de API.

Artillery tiene sobre todo licencia MPL-2.0, con algunos módulos de Azure bajo una licencia source-available. Trae de serie HTTP, WebSocket y Socket.IO, suma gRPC y Kinesis con motores adicionales, y sus comandos run-lambda y run-fargate reparten una prueba entre workers de tu propia cuenta de AWS. El comando run-aci hace lo mismo en Azure Container Instances, con una suscripción de pago a Artillery para algo más que una evaluación (comprobado el 9 de octubre de 2026).

Ideal para equipos de Node.js, pruebas mixtas de API y navegador, y empresas que ya usan AWS. Elige otra cosa si prefieres no instalar Node.js en tus generadores de carga o si las pruebas grandes tienen que correr fuera de AWS y Azure.

¿Para qué sirve Vegeta?

Para comprobaciones HTTP rápidas a ritmo constante desde la línea de comandos. Hace una sola cosa, enviar peticiones a un ritmo fijo, y la mantiene sencilla.

Vegeta es una herramienta de Go con licencia MIT que funciona como programa de línea de comandos o como biblioteca de Go, con una CLI pensada para combinarse con otras herramientas de Unix. Como mantiene constante el ritmo de peticiones en lugar de modelar usuarios, responde mejor a preguntas como «¿qué pasa a 500 peticiones por segundo?» que a reproducir recorridos de usuario.

Ideal para comprobar rápido un endpoint, hacer pruebas de capacidad a ritmo fijo y escribir scripts de shell. Elige otra cosa si necesitas recorridos de varios pasos, tiempo de reflexión o informes detallados.

¿Dónde encaja un servicio alojado como LoadFocus?

Ninguna de estas herramientas necesita un servicio alojado, pero generar una carga grande o repartida geográficamente desde tus propias máquinas da trabajo. Un servicio alojado se encarga de generar la carga y deja tus scripts como están.

LoadFocus, el editor de este sitio, es uno de esos servicios. Ejecuta tus planes de prueba de JMeter y tus scripts de k6 desde 25 regiones en la nube. No ejecuta pruebas de Gatling, Locust, Artillery ni Vegeta, así que para esas herramientas se aplican las opciones de escalado de arriba. Grafana Cloud k6 y Gatling Enterprise son las vías alojadas de los propios fabricantes para k6 y Gatling.

¿Cómo elegir entre ellas?

Parte del lenguaje que tu equipo ya escribe y de los protocolos que tienes que probar, y luego mira cómo escala cada herramienta. Eso suele reducir seis opciones a una o dos.

Después escribe la misma prueba corta con tus dos favoritas. Leerlas una al lado de la otra resuelve la mayoría de los debates más rápido que cualquier tabla de funciones, y nuestra guía Cómo hacer una prueba de carga acompaña esa primera prueba paso a paso.

FAQ

¿Qué herramienta de pruebas de carga open source es la más fácil para empezar? Para un solo endpoint HTTP, Vegeta o k6 te dan un resultado en minutos porque cada una es un único binario. Para recorridos de varios pasos, elige la herramienta cuyo lenguaje de pruebas ya escribe tu equipo.

¿Pueden las herramientas de pruebas de carga open source ejecutar pruebas distribuidas? Sí, por caminos distintos: JMeter tiene un modo remoto integrado, Locust se reparte entre máquinas de forma nativa, k6 usa el k6-operator en Kubernetes y Artillery usa AWS Lambda, Fargate o Azure Container Instances. En Gatling, generar carga desde infraestructura gestionada o privada forma parte de la edición comercial Enterprise.

¿Es JMeter mejor que k6? Ninguna es mejor en general. JMeter cubre más protocolos y encaja con el diseño de pruebas en interfaz gráfica, mientras que k6 encaja con desarrolladores que quieren pruebas como código JavaScript en la CI.