¿Cuál es el mayor número de subprocesos que es razonable ejecutar simultáneamente en Jmeter?

Quiero utilizar la mayor cantidad posible de subprocesos (para usar menos computadoras) pero sin hacer que el cuello de botella esté en el cliente.

He usado JMeter un poco y he descubierto que no es genial generar una carga realmente alta. En un 2Ghz Core2 Duo con memoria de 2 Gb, puede esperar razonablemente alrededor de 100 hilos.

Una vez dicho esto, es mejor ejecutarlo en su hardware para que la CPU de la PC no scope el 100% – un 80% -90% estable es lo mejor; de lo contrario, los resultados se verán afectados.

También probé WAPT 5 : ejecutó con éxito más de 1000 subprocesos desde la misma PC. No es gratuito, pero es más útil que JMeter pero no tiene todas las funciones.

Respuesta obsoleta desde al menos la versión 2.6 ver https://stackoverflow.com/a/11922239/460802 para obtener una más actualizada.

JMeter puede simular una carga muy alta siempre que la uses correctamente.

No escuche a Urban Legends que dicen que JMeter no puede manejar una carga alta.

Ahora en cuanto a la respuesta, depende de:

  • su poder de máquina

  • su jvm 32 bits o 64 bits

  • su memoria asignada jvm -Xmx

  • su plan de prueba (gran cantidad de beanshell, post procesador, xpath … Significa mucha CPU)

  • su configuración de os (ajustable)

  • Modo Gui / no gui

Por lo tanto, no hay una respuesta teórica, pero seguir las Mejores prácticas garantizará que JMeter tenga un buen rendimiento.

Tenga en cuenta que con jmeter puede distribuir la carga a través de pruebas remotas, lea:

  • Pruebas remotas> 15.4 Uso de un remitente de muestra diferente

Y finalmente use pruebas basadas en la nube si no es suficiente.

Lee esto para consejos de ajuste:

JMeter Wiki informa sobre casos en los que se usó JMeter con hasta 1000 hilos. Lo he usado con un máximo de 100 hilos, pero los Enlaces en el Wiki sugieren reducciones de recursos que nunca intenté.

Uno de los problemas que tuvimos con la ejecución de JMeter en Windows XP fue el límite de conexión TCP de Windows XP. Se debe eliminar el límite para poder utilizar el JMeter a todo el potencial de la estación de trabajo. Obtenga más información aquí . AFAIK, no se aplica a otros sistemas operativos.

Utilicé JMeter desde 2004 y lancé muchas pruebas de carga.

Con PC Windows 7 64 bits 4Go RAM iCore5.

Creo que JMeter puede admitir entre 300 y 400 subprocesos concurrentes para el protocolo Http (Sampler) con solo un “Escuchador de informes agregados” que escribe en los resultados del archivo de registro y los temporizadores entre las páginas de llamadas.

Para una gran prueba de carga, puede configurar JMeter con esclavos (generadores de carga) como este http://jmeter-plugins.org/wiki/HttpSimpleTableServer/

Ya hice pruebas con 11 esclavos de PC para simular 5000 hilos.

No he usado JMeter, pero la respuesta probablemente dependa de tu hardware. La mejor opción podría ser establecer métricas de rendimiento, adivinar el número de subprocesos y luego ejecutar una búsqueda binaria de la siguiente manera.

La fuente fue Wikipedia.

Número juego de adivinanzas …

Este juego bastante simple comienza algo así como “Estoy pensando en un número entero entre cuarenta y sesenta inclusive, y a tus conjeturas responderé ‘Alto’, ‘Bajo’ o ‘¡Sí!’ como podría ser el caso “. Suponiendo que N es el número de valores posibles (aquí, veintiuno como “inclusivo” fue declarado), entonces se requieren como mucho preguntas para determinar el número, ya que cada pregunta reduce a la mitad el espacio de búsqueda. Tenga en cuenta que se requiere una pregunta menos (iteración) que para el algoritmo general, ya que el número ya está restringido para estar dentro de un rango particular.

Incluso si el número que estamos adivinando puede ser arbitrariamente grande, en cuyo caso no hay límite superior N, aún podemos encontrar el número en la mayoría de los pasos (donde k es el número seleccionado (desconocido)) al encontrar primero un límite superior por doblar repetidamente. Por ejemplo, si el número fuera 11, podríamos usar la siguiente secuencia de conjeturas para encontrarlo: 1, 2, 4, 8, 16, 12, 10, 11

También se podría extender la técnica para incluir números negativos; por ejemplo, las siguientes suposiciones podrían usarse para encontrar -13: 0, -1, -2, -4, -8, -16, -12, -14, -13

Depende más del tipo de pruebas de rendimiento que realice (carga, pico, resistencia, etc.) en un servidor específico (un poco de dependencia del hardware)

Tenga en cuenta estos parámetros: la máquina cliente en la que se está enfocando la ejecución del jmeter, se asignará una cierta cantidad de memoria del montón, asegúrese de tener una asignación correcta para que el script no se salga. El más alto que había ejecutado en jmeter era 1500 en un entorno local (cliente – servidor de arco), En un arco de web, el más alto que tenía una carrera se basaba en el requisito no funcional se limitaba a 250 hilos,

por lo que idealmente depende de los tipos de pruebas de rendimiento y estilo de implementación, etc.

No hay un número estándar para esto. La cantidad máxima de hilos que puede generar desde una computadora depende completamente del hardware de la computadora y del sistema operativo. El sistema operativo ocupa por defecto cierta cantidad de CPU y la RAM.

Para conocer los hilos máximos que su computadora puede manejar, puede preparar una prueba de muestra y ejecutarla con solo unos pocos hilos. Luego, con cada ciclo de prueba, aumente la cantidad de hilos gradualmente. Durante esto, también debe controlar la CPU, la RAM, las E / S de disco y las E / S de red de su computadora. En el momento en que cualquiera de estos scope cerca del 80% o más (nuevamente para que usted decida si cerca está bien para usted o más), esa es la cantidad máxima de hilos que su computadora puede manejar. Para estar en el lado más seguro, me detendría en el número cuando la utilización del recurso alcanza el 70%.

Dependerá del hardware que ejecute, así como del script subyacente. Siempre he sentido que esta falta de claridad es el mayor problema con las herramientas tradicionales de prueba de carga. Si tiene un presupuesto pequeño ($ 200 o más, obtiene MUCHA prueba), consulte el servicio de prueba de carga de mi empresa, BrowserMob.

Además de nuestros usuarios reales de navegadores (RBU) que controlan miles de navegadores reales para realizar pruebas de carga y rendimiento, también tenemos usuarios virtuales (VU) tradicionales. Los scripts están escritos en JavaScript y pueden realizar varias llamadas HTTP.

La razón por la que lo menciono es que siempre sentí que el juego de tratar de descubrir cuántas VU puedes caber en tu hardware de carga es peligroso. Es muy fácil obtener malos resultados sin darte cuenta.

Para resolver eso para BrowserMob, adoptamos un enfoque extremadamente conservador sobre el número de VU y RBU por núcleo de CPU: no más de 1 navegador o 50 hilos por núcleo de CPU, y en ocasiones mucho menos. En el mundo de la computación en la nube, los ciclos de la CPU son tan baratos que simplemente no tiene sentido intentar sobrecargar las máquinas.