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

JMeter puede simular una Carga muy Alta siempre que la use correctamente.

No escuches a Leyendas urbanas que dicen que JMeter no puede manejar una carga alta.

Ahora, en cuanto a la respuesta, depende de:

• La potencia de su máquina

• Su jvm 32 bits o 64 bits

• Su memoria asignada jvm-Xmx

• Su plan de prueba (mucho beanshell, post procesador, xpath ... Significa un montón de cpu)

• Configuración del sistema operativo (sintonizable)

• Modo gui / no gui

Así que no hay una respuesta teórica, pero seguir Las Mejores Prácticas asegurará que JMeter funcione bien.

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

• Pruebas remotas > 15.4 Usando un remitente de muestra diferente

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

Lea esto para afinar consejos:

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips /

El Wiki de JMeter informa de casos en los que JMeter se usó 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 probé.

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. El límite debe eliminarse para ejecutar el uso del JMeter al máximo potencial de la estación de trabajo 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 soportar 300 para 400 subprocesos concurrentes para el protocolo Http (Sampler) con solo un "Oyente de informes agregado" que escribe en los resultados del archivo de registro y temporizadores entre las páginas de llamada.

Para una prueba de carga grande podría configurar JMeter con esclavos (generadores de carga) like este http://jmeter-plugins.org/wiki/HttpSimpleTableServer /

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

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

La fuente fue Wikipedia.

Juego de adivinanzas numéricas...

Este juego bastante simple comienza algo así como " Estoy pensando en un entero entre cuarenta y sesenta inclusive, y a sus 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 en la mayoría de las preguntas se requieren 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á limitado a estar dentro de un rango particular.

Incluso si el número que estamos adivinando puede ser arbitrariamente grande, en cuyo caso no hay un límite superior N, todavía podemos encontrar el número en la mayoría de los pasos (donde k es el número seleccionado (desconocido)) encontrando primero un límite superior duplicando 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 conjeturas 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 sobre la dependencia del hardware)

Tenga en cuenta estos parámetros - la máquina cliente en la que está apuntando la ejecución de jmeter, habrá una cierta cantidad de memoria de montón asignada, asegúrese de tener una asignación saludable para que el script no se equivoque. El más alto que había ejecutado en jmeter era 1500 en un entorno local (arco cliente - servidor), en una Web arco, el más alto que tenía una carrera se basó en el requisito no funcional se limitaron a 250 hilos,

Por lo tanto, idealmente depende de los tipos de pruebas de rendimiento y el estilo de implementación, etc..

No hay un número estándar para esto. El número máximo de subprocesos que puede generar desde un equipo depende completamente del hardware del equipo y del sistema operativo. El sistema operativo por defecto ocupa cierta cantidad de CPU y RAM.

Para averiguar el máximo de subprocesos que su computadora puede manejar, puede preparar una prueba de muestra y ejecutarla con solo unos pocos subprocesos. Luego, con cada ciclo de ejecución de prueba, aumente el número de hilos gradualmente. Durante esto también necesita monitorear la CPU, la RAM, E/S de disco y e/S de Red de su ordenador. En el momento en que cualquiera de estos alcance cerca o más allá del 80% (De nuevo para que usted decida si cerca está bien para usted o más allá), ese es el número máximo 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 de recursos alcanza el 70%.

Dependerá del hardware en el que se ejecute, así como del script subyacente. Siempre he sentido que esta borrosidad es el mayor problema con las herramientas tradicionales de prueba de carga. Si tienes un pequeño presupuesto (or 200 más o menos te da muchas pruebas), echa un vistazo al servicio de pruebas de carga de mi compañía , BrowserMob.

Además de nuestros Usuarios de Navegadores Reales (RBUs) que controlan miles en navegadores reales con el propósito de pruebas de rendimiento y carga, también tenemos usuarios virtuales tradicionales (VUs). Los scripts están escritos en JavaScript y pueden hacer varias llamadas HTTP.

La razón por la que lo menciono es que siempre sentí que el juego de tratar de averiguar cuántas VUs puede caber en su hardware de generación de carga es peligroso. Es muy fácil obtener malos resultados sin darse cuenta.

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