pruebas - jmeter tutorial
Prueba con JMeter: cómo ejecutar N solicitudes por segundo (4)
Al igual que con cualquier prueba de red, siempre habrá problemas, especialmente con la latencia: incluso si puede enviar exactamente 6 por segundo, se enviarán secuencialmente (así es como se envían los paquetes) y es posible que no todos coincidan. segundo, más el tiempo de procesamiento.
En general, cuando las métricas de rendimiento son específicas x por segundo, se mide a lo largo de un período de tiempo. Su API puede incluso tener un búfer, por lo que técnicamente puede enviar 6 por segundo, pero procesar 5 por segundo, con un búfer de 20, lo que significa que estaría bien para 20 segundos de tráfico, ya que habría enviado 120, que tardaría 120/5 = 24 segundos en procesarse. Pero más que eso desbordaría el buffer. Entonces enviar solo exactamente 6 en un segundo para probar es insuficiente.
En el grupo de subprocesos, tiene razón para establecer el número de subprocesos (usuarios) en 6. Luego, ejecútelo para siempre (márquelo o colóquelo en un ciclo while) y agregue un oyente como informe agregado y árbol de resultados. Se envían y responden los resultados que puede usar para verificar el material correcto (suponiendo que valide las respuestas) y en el informe agregado, puede ver cuántos de cada actividad están sucediendo por hora (obviamente multiplicar por 3600 por segundos, pero debido a esta inexactitud, es mejor ejecutarlo durante un buen período de tiempo).
Ahora se puede ejecutar la prueba de carga inicial, y como prueba más precisa, puede dejarla funcionando por más tiempo (prueba de remojo) para ver si hay otros problemas en la superficie: desbordamientos de búfer, pérdidas de memoria u otros eventos inesperados.
Necesito probar si nuestro sistema puede realizar N solicitudes por segundo. Técnicamente, son 2 solicitudes para una API, 2 solicitudes para otra y 6 solicitudes para una tercera. Pero lo importante es que deberían suceder simultáneamente, por lo que 10 solicitudes por segundo. Entonces, en JMeter creé tres grupos de subprocesos, primero define el número de subprocesos 1 y el tiempo de aceleración 0. El segundo grupo de subprocesos es el mismo y el tercer grupo de subprocesos define el número de subprocesos 6 y el tiempo de aceleración 0. eso realmente no garantiza que vaya a ejecutarlos por segundo ¿Cómo emulo eso? ¿Y cómo veo los resultados, si fue capaz de funcionar o no?
¡Gracias!
Tuve un problema similar y aquí hay dos soluciones que encontré:
Solución 1:
Puede usar Stepping Thread Group (permite configurar el número de subprocesos durante un período de tiempo determinado) con Constant Throughput Timer en él. El Temporizador de rendimiento le permite establecer el número de muestras que el hilo puede enviar por minuto (por ejemplo, si lo establece en 1, el hilo solo enviará una solicitud por minuto). Además, puede aplicar el Temporizador de rendimiento a todos los hilos en su Grupo de subprocesos o tener un Temporizador para cada subproceso con su propia configuración. Lea más sobre el temporizador de rendimiento aquí: https://www.blazemeter.com/blog/how-use-jmeters-throughput-constant-timer
Solución 2:
Use "SetUp Thread Group". Puede calcular el número de hilo y el tiempo de arranque para obtener los hilos por segundo deseados.
Podría usar ConstantThroughputTimer .
Cita de los archivos de ayuda de JMeter a continuación:
18.6.4 Temporizador de caudal constante Este temporizador introduce pausas variables, calculadas para mantener el rendimiento total (en términos de muestras por minuto) lo más cerca posible de una cifra dada. Por supuesto, el rendimiento será menor si el servidor no es capaz de manejarlo, o si otros temporizadores o elementos de prueba que consumen tiempo lo impiden. NB aunque el temporizador se denomina temporizador de rendimiento constante, el valor de rendimiento no necesita ser constante. Se puede definir en términos de una llamada de función o variable, y el valor se puede cambiar durante una prueba.
Por ejemplo, lo he usado para generar 40 solicitudes por segundo:
<ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
<stringProp name="calcMode">all active threads in current thread group</stringProp>
<doubleProp>
<name>throughput</name>
<value>2400.0</value>
<savedValue>0.0</savedValue>
</doubleProp>
</ConstantThroughputTimer>
Y eso es un resumen:
Created the tree successfully using performance/search-performance.jmx
Starting the test @ Tue Mar 15 16:28:39 CET 2011 (1300202919244)
Waiting for possible shutdown message on port 4445
Generate Summary Results + 3247 in 80,3s = 40,4/s Avg: 18 Min: 0 Max: 1328 Err: 108 (3,33%)
Generate Summary Results + 7199 in 180,0s = 40,0/s Avg: 15 Min: 1 Max: 2071 Err: 378 (5,25%)
Generate Summary Results = 10446 in 260,3s = 40,1/s Avg: 16 Min: 0 Max: 2071 Err: 486 (4,65%)
Generate Summary Results + 7200 in 180,0s = 40,0/s Avg: 14 Min: 0 Max: 152 Err: 399 (5,54%)
Generate Summary Results = 17646 in 440,4s = 40,1/s Avg: 15 Min: 0 Max: 2071 Err: 885 (5,02%)
Generate Summary Results + 7199 in 180,0s = 40,0/s Avg: 14 Min: 0 Max: 1797 Err: 436 (6,06%)
Generate Summary Results = 24845 in 620,4s = 40,0/s Avg: 15 Min: 0 Max: 2071 Err: 1321 (5,32%)
Pero realizo esta prueba dentro de mi red.