Quiero usar la mayor cantidad posible de subprocesos (para usar menos computadoras) pero sin hacer que el cuello de botella esté en el cliente.¿Cuál es el mayor número de subprocesos que es razonable ejecutar simultáneamente en Jmeter?
He usado JMeter un poco y descubrió que no es excelente para generar una carga realmente alta. En un 2Ghz Core2 Duo con memoria de 2 Gb, puede esperar razonablemente alrededor de 100 hilos.
Dicho esto, es mejor ejecutarlo en su hardware para que la CPU de la PC no alcance el 100% - un 80% -90% estable es lo mejor; de lo contrario, los resultados se verán afectados.
También he intentado WAPT 5 - ejecutó con éxito más de 1000 hilos 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 una más actualizada.
La respuesta está desactualizada a partir de JMeter 2.8 –
No he usado JMeter, pero la respuesta probablemente dependa de su 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 ...
Esta bastante simple juego comienza algo como "Estoy pensando en un número entero entre cuarenta y sesenta inclusive, y que sus conjeturas voy a responder 'Alto', 'Bajo' , ¡o si!' 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)) primero encontrando un límite superior por doblamiento repetido. 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
The JMeter Wiki informes de 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é.
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 MUCHAS pruebas), consulte el load testing service de mi empresa, BrowserMob.
Además de nuestros Usuarios del navegador real (RBU) que controlan miles de navegadores reales con el fin de realizar pruebas de rendimiento y carga, también tenemos usuarios virtuales tradicionales (VU). 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 intentar averiguar cuántas VU puede caber en el hardware de su 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 algunas veces 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.
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 poder utilizar el JMeter a pleno potencial de la estación de trabajo Más información here. AFAIK, no se aplica a otros sistemas operativos.
JMeter puede simular una carga muy alta siempre que la use correctamente.
No escuche Urban Legends que dicen que JMeter no puede soportar una carga elevada.
Ahora en cuanto a respuesta, depende de:
su potencia de la máquina
su JVM de 32 bits o 64 bits
su memoria asignada JVM -Xmx
su plan de prueba (lote de beanshell, procesador posterior, xpath ... Significa mucha CPU)
su configuración de sistema operativo (sintonizable)
Gui/modo de interfaz gráfica de usuario no
Así que no hay una respuesta teórica, pero después Best Practices asegurará JMeter se desempeña bien.
Tenga en cuenta que con jmeter se puede distribuir la carga a través de pruebas a distancia, debe decir:
Y finalmente utilizar las pruebas basadas en la nube si no es suficiente.
leer esto para sugerencias de ajuste:
que utiliza JMeter desde 2004 y que puso en marcha gran cantidad de pruebas de carga.
Con PC Windows 7 64 bits 4Go RAM iCore5.
creo JMeter puede apoyar 300 a 400 hilos concurrentes para el protocolo HTTP (Sampler) con sólo un "agregado Informe Listener" que escribe en los resultados del archivo de registro y temporizadores entre las páginas de llamadas.
Para una prueba de carga grande que podría configurar JMeter con esclavos (generadores de carga) como esto http://jmeter-plugins.org/wiki/HttpSimpleTableServer/
ya lo he hecho pruebas con 11 esclavos de PC para simular las discusiones 5000.
Es más dependiente del tipo de pruebas de rendimiento que haces (carga, pico, resistencia, etc.) en un servidor específico (un poco sobre la dependencia del hardware)
que tener en cuenta en torno a estos parámetros - la máquina cliente En el que está orientando la ejecución de 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 web, el más alto que tenía una ejecución se basaba en requisitos no funcionales se limitaban a 250 hilos,
por lo que lo ideal es que dependa 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 alcance 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%.
Yo diría que esto depende de su hardware ... –
La respuesta aceptada está desactualizada a partir de las versiones recientes de JMeter. –
Se gasta en todo lo que no nos ha contado: sistema operativo, hardware, servidor que está probando, lo mismo para el cliente, ... No es una pregunta real. – EJP