JMeter max. límite de hilo

Question

1. ¿Podría decirme el límite máximo de no. de subprocesos que puedo usar en JMeter 2.4 para realizar una prueba de carga?

2. ¿Hay alguna diferencia en tomar todos los hilos en un solo ciclo o tomando menos no? de hilos y bucle de inicialización para lograr el mismo no. de usuarios/hilos?

Ejemplo:

No. of threads=500 
Ramp up=1000 
Loop=1 

si es igual que

No. of threads=50 
Ramp up=100 
Loop=10 

o hay alguna diferencia en términos de resultado?

Answer 1

1. El número máximo de hilos está determinada por muchos factores, consulte esta respuesta https://stackoverflow.com/a/11922239/460802

2. Hay una gran diferencia en lo que usted propone.

   • "500 hilos, Bucle 1" Significa 500 hilos AL MISMO TIEMPO haciendo el ciclo UNA VEZ.
   • "50 hilos, lazo 10" Significa solo 50 hilos AL MISMO TIEMPO haciendo el ciclo DIEZ VECES.

En teoría se obtiene el mismo número de resultados (500), pero que están golpeando el servidor de una manera muy diferente.

Answer 2

La cantidad máxima de usuarios depende de su sistema operativo, memoria RAM libre y conexión. Win XP está limitado a 3000 procesos al mismo tiempo. En Linux hay más de 3000 pero no sé cuánto. Tenga cuidado de que pruebe el servidor y si inicia 3000 hilos en su máquina, necesitará muchos recursos y la prueba no será real. Prefiero comenzar un máximo de 300 usuarios por máquina. Si desea aumentar la cantidad de usuarios que usar pruebas distribuidas (use más máquinas como ataque DoS). En teoría es el mismo número de solicitud, pero la complejidad del tiempo no es la misma.

Answer 3

1: Por supuesto depende mucho de la máquina que ejecuta JMeter, pero si el kilometraje cuenta puedo darle algunas pistas. JMeter le permite ejecutar múltiples procesos en el mismo cuadro, y generalmente es bastante confiable generando hasta 200 hilos por instancia de JMeter. Si necesita más que eso, le recomendaría usar varias instancias de JMeter. Una máquina moderna con algunos ajustes puede generar fácilmente de 500 a 1000 hilos. Con Linux, probablemente necesite aumentar el número máximo de descriptores de archivos (see here).

Ayuda mucho ejecutar JMeter sin una GUI, escribir informes/datos gráficos en un archivo para representarlos más tarde. También debe prestar atención a sus limitaciones de red. Sería fácil para un servidor dentro de una red Gbps generar miles de solicitudes, pero una computadora portátil que comparta un enrutador de 54 Mbps sería mucho más limitada. Intenta dividir tu conexión real con el servidor por el tamaño de las solicitudes, y luego sabrás si el ancho de banda te limitará. Preste especial atención a la configuración de JMeter para descargar o no los archivos a los que se hace referencia en una respuesta HTML.

Espero que haya podido ayudar.

2: Es exactamente lo que explicó BlackGaff: "500 hilos, Bucle 1" Significa 500 hilos AL MISMO TIEMPO haciendo el ciclo UNA VEZ. "50 hilos, lazo 10" Significa solo 50 hilos AL MISMO TIEMPO haciendo el ciclo DIEZ VECES.

Answer 4

1. No creo que haya ningún límite de hilo en el propio JMeter si su máquina puede manejarlo. La idea básica de las pruebas debería ser que, la conmutación de hilo y el tiempo de espera no deberían afectar demasiado las métricas de rendimiento real.

2. Hay una gran diferencia entre los dos casos. En el primer caso, peor escenario, tendrá 500 usuarios concurrentes. En el segundo caso, el número máximo de usuarios simultáneos será 50. El tiempo medio para el escenario 1 será mayor que el tiempo promedio para el escenario 2.

Answer 5

Esto es muy común para pegado aquí después de la creación de un escenario y casos de prueba, tenemos que ejecutar usando JMeter y tenemos que fijar el valor de cuántos usuarios o subprocesos se les permite usar en JMeter Thread Group. No queremos acelerar nuestro generador de carga o nuestra instancia de JMeter. Así que, básicamente, es necesario ajustando en ambos casos. De lo contrario, la salida de la prueba no tendrá valor y perderemos horas de nuestro tiempo. Así que aquí son las cosas que tenemos que tener en cuenta: -

• JMeter es una herramienta de Java que se ejecuta con JVM. Para obtener la máxima capacidad, tenemos que proporcionar el máximo de recursos a JMeter durante execution.First, tenemos que aumentar el tamaño del montón (directorio bin de JMeter interior, obtenemos jmeter.bat/sh)

HEAP=-Xms512m –Xmx512m 

Significa que el tamaño de pila asignado por defecto es mínimo de 512 MB, máximo de 512 MB. Configúrelo según su propia configuración de PC. Tenga en cuenta que el sistema operativo también necesita cierta cantidad de memoria, por lo que no debe asignarle toda la memoria RAM física.

• A continuación, añadir memoria tasa de asignación

NEW=-XX:NewSize=128m -XX:MaxNewSize=512m

Esto significa que la memoria se incrementará a este ritmo. Debe tener cuidado, porque, si su generación de carga es muy alta al principio, podría necesitar aumentar. Tenga en cuenta que fragmentará su espacio de almacenamiento dentro de JVM si el rango es demasiado amplio. Si es así, Garbage Collector necesita trabajar más para limpiar.

• JMeter es una aplicación de GUI de Java. También tiene la edición sin GUI que requiere menos recursos (CPU/RAM). Si ejecutamos JMeter en modo no GUI, consumirá menos recursos y podremos ejecutar más subprocesos.

• Deshabilitar TODOS los oyentes: Durante la ejecución de prueba. Solo son para depurar y usarlos para diseñar el guión deseado.

oyentes deben ser desactivados durante las pruebas de carga. Permitirlos genera gastos generales adicionales, que consumen recursos valiosos que son necesarios para los elementos más importantes de su prueba.

• Siempre trate de utilizar el software de -Up-hasta la fecha. Mantenga su Java y JMeter actualizado.

• ¡No olvide que cuando se trata de almacenar solicitudes y encabezados de respuesta, los resultados de las afirmaciones y los datos de respuesta pueden consumir mucha memoria! Intente no almacenar estos valores en JMeter a menos que sea absolutamente necesario.

Así que en resumen, si no hay oyentes se incluyen en escritura JMeter, sin supervisión dentro ejecuta el servidor de JMeter, sobrecarga de la red/barreras y los guiones de JMeter se optimizan entonces aquí es un cálculo aproximado:

The total number of concurrent user = (total allocable memory)/(Size of all requests)

hay que estimar el número de usuarios simultáneos /hilo (hilos activos) sólo en ter ms de su escenario de carga.

Además, es necesario controlar si sus servidores Memory consumption, CPU usages están ejecutando por debajo del 80% o no. Si estos usos exceden el 80%, considere esas pruebas como poco confiables como un informe.

Para una comprensión mejor y más elaborada estos dos blogs How many users JMeter can support? y 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure deben ayudar.