your xmx512m xms512m the test modify memoria meet increase error batch aumentar java stack jmeter heap performance-testing

java - xmx512m - ¿Cómo enviar más de 4000 solicitudes en exactamente 1 segundo?



jmeter 4.0 heap size (4)

Tengo una HTTP GET request . Necesito enviar la solicitud al servidor de aplicaciones más de 4000 veces exactamente en 1 segundo.

Estoy enviando estas solicitudes utilizando JMeter. He tomado rastros etéreos cada vez para cada prueba usando una herramienta de detección ( Wireshark ).

He intentado lograr esto desde una máquina, varias máquinas (paralelas) e incluso en modo distribuido.

En realidad, los resultados de JMeter no son mi preocupación aquí. La preocupación de esta prueba es ver que 4000 solicitudes llegan al servidor en un segundo en la herramienta sniffer.

He encontrado casi 2500 solicitudes en 1 sec en traza etérea mientras utilizaba el siguiente plan de prueba de JMeter.

Number of Threads= 4000 Ramp-Up Periods = 0 (Though it is depricated) Loop count= 1

Cuando uso el número de subprocesos como 2500 , recibí una 2200 request casi 2200 request que llegó al servidor en un segundo en la traza etérea.

La respuesta del servidor para esa solicitud no es mi preocupación aquí. Solo quiero asegurarme de que la solicitud 4000 enviada por JMeter llegue al servidor de aplicaciones en un segundo.

ACTUALIZAR:

Caso 1: (4000 hilos)

Number of Threads= 4000 Ramp-Up Periods = 0 Loop count= 1

Salida para el caso 1:

JMeter (Ver resultados en la tabla) : 2.225 segundos para iniciar 4000 solicitudes.

Rastro etéreo : 4,12 segundos para que 4000 solicitudes lleguen al servidor.

Caso 2: (3000 hilos)

JMeter (ver resultados en la tabla) : 1.83 segundos para iniciar 3000 solicitudes.

Rastro etéreo : 1.57 segundos para que 3000 solicitudes lleguen al servidor.

Caso 3: (2500 hilos)

JMeter (ver resultados en la tabla) : 1,36 segundos para iniciar 2500 solicitudes.

Rastro etéreo : 2,37 segundos para que 2500 solicitudes lleguen al servidor.

Caso 4: (2000 hilos)

JMeter (ver resultados en la tabla) : 0.938 segundos para iniciar 2000 solicitudes.

Rastro etéreo : 1.031 segundos para que 2000 solicitudes lleguen al servidor.

I have run these test from only one machine. No listeners added. Non-Gui mode. No assertions in my scripts. Heap size: 8GB

Por lo tanto, no entiendo por qué los resultados de JMeter y los rastros etéreos difieren entre sí. También he intentado sincronizar el temporizador para lograr este escenario.

Dado que 4000 hilos son demasiado pesados, tal vez tenga que probar esto en modo Distribuido. También he probado con el modo distribuido (1 maestro, 2 esclavos). Tal vez mi guión está mal.

¿Es posible ver en la traza etérea que mis 4000 solicitudes llegan al servidor en 1 segundo?

¿Cuál será la secuencia de comandos de JMeter para lograr este escenario en modo distribuido?

  1. Si su PC no es suficiente, debe usar pruebas distribuidas en Jmeter
  2. Tenga en cuenta que, en teoría, puede enviar 4000 solicitudes por segundo; pasarán algún tiempo de camino al servidor, por lo que es probable que no lleguen en 1 segundo. Para evitar esto, intente usar el ancho de banda alto de LAN (por ejemplo, puede alojar su servidor en la nube de Azure e instalar Jmeter en la nube también).
  3. Si no tiene éxito con JMeter, intente utilizar la herramienta Tank Esta herramienta especializada en carga alta, y debería ser posible enviar hasta 10k solicitudes en 1 segundo desde 1 máquina.

¿Qué tal comenzar con si el servidor está configurado correctamente para evitar tal carga? Las solicitudes pueden ser de cualquier tipo. Si se trata de solicitudes estáticas, trabaje para garantizar que el número mínimo absoluto de éstas llegue a su servidor de origen debido a las políticas o la arquitectura de almacenamiento en caché, como

  • Si tiene usuarios que regresan y no tiene CDN, asegúrese de que su política de caché se esté almacenando en el cliente, caducando con su programa de construcción. Esto evita la repetición de solicitudes de los visitantes que regresan
  • Si no tiene usuarios que regresan ni CDN, asegúrese de que su política de caché esté configurada en al menos el 120% del retraso máximo de página a página visible en sus registros para un conjunto de usuarios determinado
  • Si tiene un CDN, asegúrese de que todos los encabezados de solicitud estática, los encabezados 301 y 404 estén configurados para permitir que su CDN almacene en caché sus solicitudes para que caduque con su nueva programación de inserción de compilación.
  • Si no tiene un CDN, considere un modelo donde coloque todos los recursos estáticos en un servidor dedicado donde todo en ese servidor esté marcado para el almacenamiento en caché en el cliente a un nivel alto. También puede enfrentar ese servidor con barniz o calamar como un proxy de almacenamiento en caché para tomar la carga

Por lo general, sospecho que un problema de diseño en juego con este alto nivel de solicitud es consistente. 4000 solicitudes por segundo se convierten en 14,400,000 solicitudes por hora y 345,600,000 en un período de 24 horas.

Sobre una base de proceso, también sugeriría un mínimo de tres generadores de carga: dos para carga primaria y uno para un usuario virtual de control de un único usuario virtual para su proceso empresarial. En su modelo actual para todos en un generador de carga, no tiene ningún elemento de control para determinar la sobrecarga impuesta por la sobrecarga potencial de su generador de carga. El uso del elemento de control le ayudará a determinar si tiene un sesgo impuesto por el generador de carga en la conducción de la carga. Esencialmente, tiene un recurso agotador que está agregando un corte de velocidad en su generador de carga. Elija una filosofía de carga deliberada en sus generadores de carga. Agregar otro generador de carga es más barato que el gasto de capital político cuando alguien ataca su prueba por falta de un elemento de control y luego necesita volver a ejecutar la prueba. También es mucho menos costoso que perseguir a un fantasma de ingeniería que aparece como un sistema lento pero que en realidad es un generador de carga sobrecargada.

¿Quieres quedarte con JMeter? De Httperf contrario, Httperf es una herramienta decente y fácil de usar:

httperf --server=www.example.com --rate=4000 --num-conns=4000

por ejemplo.

Espero que esto ayude un poco, aunque no del todo lo que pediste.