it-swarm.dev

Pruebas con JMeter: cómo ejecutar N solicitudes por segundo

Necesito probar si nuestro sistema puede realizar N solicitudes por segundo. Técnicamente, son 2 solicitudes a una API, 2 solicitudes a otra y 6 solicitudes a la tercera. Pero lo importante es que sucedan simultáneamente: 10 solicitudes por segundo. Entonces, en JMeter he creado 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. Pero eso realmente no garantiza que los ejecutará por segundo ¿Cómo emulo eso? ¿Y cómo veo los resultados, si fue capaz de funcionar o no?

¡Gracias!

49
alexeypro

Al igual que con cualquier prueba de red, siempre habrá problemas, especialmente con la latencia, incluso si podría enviar exactamente 6 por segundo, se enviarán secuencialmente (así es como se envían los paquetes) y puede que no todos lleguen en ese segundo, más el tiempo de procesamiento.

En general, cuando las métricas de rendimiento específicas x por segundo, se miden durante un período de tiempo. Su API incluso puede tener un búfer, por lo que técnicamente podría enviar 6 por segundo, pero procesar 5 por segundo, con un búfer de 20, lo que significa que estaría bien durante 20 segundos de tráfico, ya que habría enviado 120, que tomaría 120/5 = 24 segundos para procesar. Pero nada más que eso desbordaría el búfer. Por lo tanto, enviar exactamente 6 en un segundo para probar es insuficiente.

En el grupo de subprocesos, tiene razón al establecer el número de subprocesos (usuarios) en 6. Luego ejecútelo en bucle para siempre (márquelo o colóquelo en un bucle while) y agregue un receptor como informe agregado y árbol de resultados. Los resultados que puede usar para verificar que se están enviando y respondiendo las cosas correctas (suponiendo que valide las respuestas) y en el informe agregado, puede ver cuántas de cada actividad está sucediendo por hora (obviamente, multiplique 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 en funcionamiento durante más tiempo (prueba de remojo) para ver si surgen otros problemas: desbordamientos del búfer, fugas de memoria u otros eventos inesperados.

33
Mark Mayo

Podrías usar ConstantThroughputTimer.

Cita de los archivos de ayuda de JMeter a continuación:

18.6.4 Temporizador de rendimiento 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 mucho tiempo lo impiden. nótese bien aunque el temporizador se llama 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 ejecuto esta prueba dentro de mi red.

65
lb_lb
18
Andrey Pokhilko

Tuve un problema similar y aquí hay dos soluciones que encontré:

Solución 1:
Puede usar el grupo de subprocesos progresivos (permite establecer etapas de aumento del número de subprocesos durante períodos de tiempo establecidos) con el temporizador de rendimiento constante. El temporizador de rendimiento le permite establecer el número de muestras que el hilo puede enviar por minuto (por ejemplo, si lo configura 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 hilos o tener un temporizador para cada hilo 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:
Utilice "Configurar grupo de subprocesos". Puede calcular el número de subprocesos y el tiempo de aceleración para obtener subprocesos por segundo deseado.

1
Yury Ustsinchyk

Puede usar Programar función de comentarios y también necesitará Grupo de subprocesos de concurrencia

0
raman rayat