¿Realizar una prueba de esfuerzo en una aplicación web?

En el pasado, utilicé la herramienta de esfuerzo de aplicaciones web de Microsoft y Pylot para probar las aplicaciones web. Había escrito una página de inicio simple, una secuencia de comandos de inicio de sesión y un recorrido por el sitio (en un sitio de comercio electrónico agregando algunos artículos a un carrito y finalizando la compra).

Simplemente golpear la página de inicio con un puñado de desarrolladores casi siempre localizaría un problema importante. Surgirían más problemas de escalabilidad en la segunda etapa, y aún más, después del lanzamiento.

La URL de las herramientas que utilicé fueron Microsoft Homer (también conocida como Herramienta de estrés de aplicaciones web de Microsoft ) y Pylot .

Los informes generados por estas herramientas nunca tuvieron mucho sentido para mí, y pasaría muchas horas tratando de averiguar qué tipo de carga concurrente podría soportar el sitio. Siempre valió la pena porque siempre aparecían los errores más estúpidos y los cuellos de botella (por ejemplo, configuraciones incorrectas del servidor web).

¿Qué ha hecho, qué herramientas ha usado y qué éxito ha tenido con su enfoque? La parte que es más interesante para mí es encontrar una especie de fórmula significativa para calcular el número de usuarios concurrentes que una aplicación puede admitir a partir de los números informados por la aplicación de prueba de esfuerzo.

Aquí hay otro voto para JMeter .

JMeter es una herramienta de prueba de carga de código abierto, escrita en Java. Es capaz de probar varios tipos de servidores diferentes (por ejemplo, web, servicios web, base de datos, prácticamente cualquier cosa que use solicitudes básicamente).

Sin embargo, tiene una curva de aprendizaje pronunciada una vez que empiezas a realizar pruebas complicadas, pero vale la pena. Puede ponerse en marcha muy rápidamente y, dependiendo del tipo de prueba de esfuerzo que desee hacer, eso podría estar bien.

Pros:

• Herramienta de código abierto / gratuita del proyecto Apache (ayuda con la compra)
• Fácil de comenzar y fácil de usar una vez que comprenda los conceptos básicos. (Es decir, cómo crear una solicitud, cómo crear una aserción, cómo trabajar con variables, etc.).
• Muy escalable He realizado pruebas con 11 máquinas que generan carga en el servidor con casi un millón de visitas / hora. Fue mucho más fácil de configurar de lo que esperaba.
• Tiene una comunidad activa y buenos recursos para ayudarlo a ponerse en marcha. Lea primero los tutoriales y juegue con ellos por un tiempo.

Contras:

• La interfaz de usuario está escrita en Swing. (ugh!)
• JMeter funciona analizando el texto de respuesta devuelto por el servidor. Entonces, si está buscando validar cualquier tipo de comportamiento de JavaScript, no tiene suerte.
• La curva de aprendizaje es empinada para los no programadores. Si está familiarizado con las expresiones regulares, ya está por delante del juego.
• Hay un gran número de idiotas ( insertar improperios ) en el foro de soporte que hacen preguntas estúpidas que podrían resolverse fácilmente si le dieran a la documentación una mirada superficial. ('¿Cómo uso JMeter para hacer una prueba de esfuerzo de mi GUI de Windows? Aparece con bastante frecuencia).
• Los informes "listos para usar" dejan mucho que desear, particularmente para pruebas más grandes. En la prueba que mencioné anteriormente, terminé teniendo que escribir una aplicación de consola rápida para hacer algunas de las conversiones 'xml-logfile' a 'html'. Sin embargo, eso fue hace unos años, por lo que es probable que ya no sea necesario.

He usado The Grinder . Es de código abierto, bastante fácil de usar y muy configurable. Está basado en Java y usa Jython para los scripts. Lo ejecutamos contra una aplicación web .NET, así que no piense que es una herramienta exclusiva de Java (por su naturaleza, cualquier herramienta de estrés web no debería estar vinculada a la plataforma que utiliza).

Hicimos algunas cosas interesantes con él ... éramos una aplicación de telecomunicaciones basada en la web, así que un uso genial que configuré fue imitar marcar un número a través de nuestra aplicación web, luego usé una herramienta de respuesta automática que teníamos (que era básicamente un tutorial aplicación de Microsoft para conectarse a su servidor RTC LCS ... que es a lo que se conecta Microsoft Office Communicator en una red local ... y luego se modifica para responder llamadas automáticamente). Esto nos permitió usar esto en lugar de una costosa herramienta de telefonía llamada The Hammer (o algo así).

De todos modos, también utilizamos la herramienta para ver cómo se mantenía nuestra aplicación bajo alta carga, y fue muy efectiva para encontrar cuellos de botella. La herramienta ha incorporado informes para mostrar cuánto tardan las solicitudes, pero nunca la usamos. Los registros también pueden almacenar todas las respuestas y demás, o registros personalizados.

Recomiendo encarecidamente esta herramienta, muy útil por el precio ... pero espero hacer una configuración personalizada (tiene un proxy incorporado para grabar un script, pero puede necesitar personalización para capturar algo como sesiones ... Lo sé Tuve que personalizarlo para utilizar una sesión única por hilo).

Un poco tarde para esta fiesta. Estoy de acuerdo en que Pylot es la mejor herramienta emergente de código abierto que existe. Es fácil de usar y trabaja activamente por un gran tipo ( Corey Goldberg ). Como fundador de OpenQA , también estoy feliz de que Pylot ahora aparezca en nuestra página de inicio y utilice parte de nuestra infraestructura (es decir, los foros).

Sin embargo, también decidí recientemente que todo el concepto de prueba de carga era defectuoso: emular el tráfico HTTP, con aplicaciones tan complejas como se han vuelto, es un fastidio. Por eso creé la herramienta comercial BrowserMob. Es un servicio de prueba de carga externa que utiliza Selenium para controlar navegadores web reales cuando se reproduce la carga.

Obviamente, el enfoque requiere una tonelada más de hardware que las técnicas de prueba de carga normales, pero el hardware en realidad es bastante barato cuando se usa la computación en la nube. Y un buen efecto secundario de esto es que la secuencia de comandos es mucho más fácil que la prueba de carga normal. No tiene que hacer ninguna coincidencia de expresiones regulares avanzada (como JMeter requiere) para extraer las cookies, el estado de sesión de .NET, los parámetros de solicitud de Ajax, etc. Dado que está utilizando navegadores reales, simplemente hacen lo que se supone que deben hacer.

Perdón por lanzar descaradamente un producto comercial, pero espero que el concepto sea interesante para algunas personas y al menos les haga pensar en nuevas formas de lidiar con las pruebas de carga cuando tienes acceso a un montón de hardware adicional.

He usado JMeter . Además de probar el servidor web, también puede probar el servidor de base de datos, los servicios de mensajería y los servidores de correo electrónico.

ab , asedio , Tsung , httperf , Arrolla , Pylot, petición-log-analizador , perftools

Para un uso simple, prefiero ab (punto de referencia de apache) y sitio, luego se necesita uno ya que ab no admite cookies y crearía sesiones interminables desde el sitio dinámico.

ambos son simples de comenzar:

ab -c n -t 30 url

siege -b -c n -t 30s url

El asedio puede correr con más urls.

La última versión de asedio activa detalladamente en siegerc, lo cual es molesto. solo puede deshabilitarlo editando ese archivo ( /usr/local/etc/siegerc).

Para un servicio basado en la web, consulte loader.io .

Resumen:

loader.io es un servicio gratuito de prueba de carga que le permite probar sus aplicaciones / apis web con miles de conexiones simultáneas.

También tienen una API .

Como esta pregunta aún está abierta, también podría opinar.

La buena noticia es que en los últimos 5 años más o menos las herramientas de código abierto realmente han madurado y despegado en el espacio, la mala noticia es que hay muchas de ellas por ahí.

Aquí están mis pensamientos: -

Jmeter vs Grinder

Jmeter se maneja a partir de una especificación de estilo XML, que se construye a través de una GUI.

Grinder utiliza secuencias de comandos Jython dentro de un marco de Java multiproceso, por lo que está más orientado a los programadores.

Ambas herramientas manejarán HTTP y HTTPS y tienen un grabador proxy para comenzar. Ambas herramientas utilizan el modelo de Controlador para manejar múltiples agentes de prueba, por lo que la escalabilidad no es un problema (dado el acceso a la Nube).

Cual es mejor:-

Una decisión difícil ya que la curva de aprendizaje es empinada con ambas herramientas a medida que ingresa a los requisitos de secuencias de comandos más complicados para la reescritura de url, la correlación, el suministro de datos únicos por usuario virtual y la simulación de usuarios nuevos o recurrentes (al manipular los encabezados HTTP).

Dicho esto, comenzaría con Jmeter ya que esta herramienta tiene muchos seguidores y hay muchos ejemplos y tutoriales en la web para usar esta herramienta. Si te encuentras con un "obstáculo", eso es algo que no puedes hacer "fácilmente" con Jmeter, entonces echa un vistazo al Grinder. La buena noticia es que ambas herramientas tienen el mismo requisito de Java y una solución 'mezclar y combinar' no está fuera de discusión.

Algo nuevo para agregar: navegadores sin cabeza que ejecutan varias instancias de Selenium WebDriver.

Este es un enfoque relativamente nuevo porque se basa en la disponibilidad de recursos que ahora se pueden aprovisionar desde la nube. Con este enfoque, se toma un script Selenium (WebDriver) y se ejecuta dentro de un navegador sin cabeza (es decir, WebDriver = Nuevo controlador HtmlUnitDriver ()) en varios subprocesos.

Por experiencia, se pueden ejecutar alrededor de 25 instancias de 'navegadores sin cabeza' desde la instancia pequeña de Amazon M1.

Lo que esto significa es que todos los problemas de correlación y reescritura de URL desaparecen a medida que reutiliza sus scripts de prueba funcional para convertirse en scripts de prueba de rendimiento.

La escalabilidad se ve comprometida ya que se necesitarán más máquinas virtuales para manejar la carga, en comparación con un controlador HTTP como Grinder o Jmeter. Dicho esto, si está buscando manejar 500 usuarios virtuales, entonces con 20 instancias pequeñas de Amazon (6 centavos por hora cada una) a un costo de solo $ 1.20 por hora le brinda una carga muy cercana a la experiencia real del usuario.

Además, hay un impresionante marco de langosta de código abierto distribuido y escalable que utiliza greenlets . Es excelente para simular una enorme cantidad de usuarios simultáneos.

Recientemente comenzamos a usar Gatling para pruebas de carga. Recomiendo probar esta herramienta para pruebas de carga. Habíamos usado SOASTA y JMETER en el pasado. Nuestra razón principal para considerar Gatling es la siguiente:

• Grabador para grabar el escenario
• Usando Akka y Netty que ofrece un mejor rendimiento en comparación con el modelo Jmeter Threading
• DSL Scala, que es muy fácil de mantener en comparación con Jmeter XML
• Fácil de escribir las pruebas, no te asustes si es scala.
• Informes

Déjame darte un ejemplo simple para escribir el código usando el Código Gatling:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Sin embargo, puede hacerlo lo más complicado posible. Una de las características que se destacan para Gatling es la presentación de informes, que es muy detallada.

Aquí hay algunos enlaces: Tutorial de
Gatling
Gatling

Recientemente di una charla sobre esto, puedes pasar por la charla aquí:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Esta es una vieja pregunta, pero creo que las nuevas soluciones son dignas de mención. Pagar LoadImpact: http://www.loadimpact.com .

Probé WebLoad es una herramienta bastante limpio. Viene con un script de prueba IDE que le permite registrar la acción del usuario en un sitio web. También dibuja un gráfico mientras realiza una prueba de esfuerzo en su servidor web. Pruébelo, lo recomiendo encarecidamente.

Intentando todo lo mencionado aquí, encontré el cargador de rizos como el mejor para mis propósitos. Interfaz muy fácil, monitoreo en tiempo real, estadísticas útiles, desde las cuales construyo gráficos de rendimiento. Todas las características de libcurl están incluidas.

Blaze meter tiene una extensión de cromo para grabar sesiones y exportarlas a JMeter (actualmente requiere inicio de sesión). También tiene la opción de pagarles dinero para ejecutarlo en su clúster de servidores JMeter (su precio parece mucho mejor que LoadImpact, que acabo de dejar de usar):

• BlazeMeter Chrome Extension
• Entrada de blog al respecto

No tengo ninguna asociación con ellos, solo me gusta el aspecto de su servicio, aunque todavía no he usado la versión paga.

Hiciste esta pregunta hace casi un año y no sé si todavía estás buscando otra forma de comparar tu sitio web. Sin embargo, dado que esta pregunta aún no está marcada como resuelta, me gustaría sugerir el servicio web gratuito LoadImpact (por cierto, no afiliado). Acabo de recibir este enlace a través de Twitter y me gustaría compartir este hallazgo. Crean una buena visión general razonable y por unos pocos dólares más obtienes el "modo de impacto total". Esto probablemente suena extraño, pero buena suerte empujando y frenando su servicio :)

Encontré que IBM Page Detailer también es una herramienta interesante para trabajar.

He usado openSTA .

Esto permite grabar una sesión con un sitio web y luego reproducirla mediante un lenguaje de script relativamente simple.

Puede probar fácilmente los servicios web y escribir sus propios scripts.

Le permite agrupar los scripts en una prueba de la forma que desee y configurar el número de iteraciones, el número de usuarios en cada iteración, el tiempo de aceleración para presentar a cada nuevo usuario y el retraso entre cada iteración. Las pruebas también se pueden programar en el futuro.

Es de código abierto y gratuito.

Produce una serie de informes que se pueden guardar en una hoja de cálculo. Luego usamos una tabla dinámica para analizar y graficar fácilmente los resultados.

Usamos la herramienta de Microsoft mencionada: Herramienta de esfuerzo de aplicaciones web de Microsoft. Es la herramienta más fácil que he usado. Está limitado de muchas maneras, incluida la posibilidad de alcanzar el puerto 80 en pruebas creadas manualmente. Pero, su facilidad de uso significa que en realidad se acostumbra.

Complementamos la carga de esta herramienta con otras herramientas, incluyendo OpenSTA y arañas de verificación de enlaces.

JMeter se ve bien desde mi evaluación inicial, espero incluirlo en nuestra integración continua en el futuro. Pero, JMeter es complejo y no trivial de implementar.

Sugeriría abrir otra pregunta con respecto a la interpretación de los resultados de la herramienta de estrés de la EM.

Visual Studio Test Edition 2010 (2008 bueno también). Esta es una herramienta realmente fácil y poderosa para crear pruebas de carga / web.

La ventaja con esta herramienta cuando se usa contra servidores Windows es que obtienes acceso integrado a todas las estadísticas del servidor perfmon en tu informe. Realmente util.

La otra ventaja es que con el proyecto Visual Studio puede integrar una "Sesión de rendimiento" que perfilará la ejecución del código de su sitio web.

Si está sirviendo páginas web desde un servidor de Windows, esta es la mejor herramienta que existe.

Sin embargo, se requiere una licencia separada y costosa para usar varias máquinas para probar la carga de la aplicación.

Hemos desarrollado un proceso que trata la medición de carga y rendimiento como una preocupación de primera clase, como usted dice, dejarlo al final del proyecto tiende a decepcionar ...

Por lo tanto, durante el desarrollo, incluimos pruebas multiusuario muy básicas (usando selenio), que verifican la locura básica, como la administración de sesiones interrumpidas, problemas obvios de concurrencia y problemas obvios de contención de recursos. Los proyectos no triviales incluyen esto en el proceso de integración continua, por lo que recibimos comentarios muy regulares.

Para proyectos que no tienen requisitos de rendimiento extremos, incluimos pruebas de rendimiento básicas en nuestras pruebas; generalmente, escribimos las pruebas usando BadBoy, y las importamos a JMeter, reemplazando los detalles de inicio de sesión y otras cosas específicas del hilo. Luego los incrementamos hasta el nivel en que el servidor maneja 100 solicitudes por segundo; Si el tiempo de respuesta es inferior a 1 segundo, generalmente es suficiente. Lanzamos y seguimos con nuestras vidas.

Para proyectos con requisitos de rendimiento extremos, todavía usamos BadBoy y JMeter, pero ponemos mucha energía en comprender los cuellos de botella en los servidores de nuestro equipo de prueba (servidores web y de bases de datos, por lo general). Hay una buena herramienta para analizar los registros de eventos de Microsoft que ayuda mucho con esto. Por lo general, encontramos cuellos de botella inesperados, que optimizamos si es posible; eso nos da una aplicación lo más rápida posible en "1 servidor web, 1 servidor de base de datos". Luego, generalmente implementamos en nuestra infraestructura de destino y utilizamos uno de los servicios "Jmeter en la nube" para volver a ejecutar las pruebas a escala.

Una vez más, los informes PAL ayudan a analizar lo que sucedió durante las pruebas: a menudo se ven cuellos de botella muy diferentes en los entornos de producción.

La clave es asegurarse de que no solo realice sus pruebas de estrés, sino que también recopile la información que necesita para comprender el rendimiento de su aplicación.

Hay muchas buenas herramientas mencionadas aquí. Me pregunto si las herramientas son una respuesta a la pregunta: "¿Cómo hace una prueba de esfuerzo para una aplicación web?" Las herramientas realmente no proporcionan un método para enfatizar una aplicación web. Esto es lo que sé:

Las pruebas de resistencia muestran cómo falla una aplicación web al responder a una creciente población de usuarios. Las pruebas de tensión muestran cómo funciona la aplicación web mientras falla. La mayoría de las aplicaciones web actuales, especialmente las aplicaciones web sociales / móviles, son integraciones de servicios. Por ejemplo, cuando Facebook tuvo su interrupción en mayo de 2011, no pudo iniciar sesión en la aplicación web de Pepsi.com. La aplicación no falló por completo, solo una gran parte de su función normal no está disponible para los usuarios.

Las pruebas de rendimiento muestran la capacidad de una aplicación web para mantener tiempos de respuesta independientes de la cantidad de usuarios que la usan simultáneamente. Por ejemplo, una aplicación que maneja 10 transacciones por segundo con 10 usuarios concurrentes debe manejar 20 transacciones por segundo a 20 usuarios. Si la aplicación maneja menos de 20 transacciones por segundo, los tiempos de respuesta son cada vez más largos y la aplicación no puede lograr escalabilidad lineal.

Además, en el ejemplo anterior, el recuento de transacciones por segundo debe ser solo de operaciones exitosas de un caso de uso de prueba / flujo de trabajo. Las fallas generalmente ocurren en períodos de tiempo más cortos y harán que la medición de TPS sea demasiado optimista. Las fallas son importantes para una prueba de estrés y rendimiento, ya que también generan carga en la aplicación.

Escribí la metodología PushToTest en la Guía del usuario de TestMaker en http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker viene en dos sabores: versión de comunidad de código abierto (GPL) y TestMaker Enterprise (comercial con gran soporte profesional).

-Franco

Eche un vistazo a LoadBooster ( https://www.loadbooster.com ). Utiliza el navegador sin cabeza PhantomJS / CasperJs para probar sitios web. Phantomjs analizará y renderizará cada página, ejecutará el script del lado del cliente. El enfoque de navegador sin cabeza es más fácil de escribir escenarios de prueba para admitir aplicaciones complejas de AJAX Web 2.0, navegación del navegador, clic del mouse y pulsaciones de teclas en el navegador o esperar hasta que exista un elemento en DOM. LoadBooster también admite el script HTML de selenio.

Descargo de responsabilidad: trabajo para LoadBooster.

Pruebe ZebraTester, que es mucho más fácil de usar que jMeter. He usado jMeter durante mucho tiempo, pero el tiempo total de configuración para una prueba de carga siempre fue un problema. Aunque ZebraTester no es de código abierto, el tiempo que he ahorrado en los últimos seis meses lo compensa. También tienen un portal SaaS que puede usarse para ejecutar pruebas rápidamente utilizando sus generadores de carga.

Una nota más, para nuestra aplicación web, descubrí que teníamos grandes problemas de rendimiento debido a la disputa entre hilos sobre bloqueos ... por lo que la moraleja era pensar en el esquema de bloqueo con mucho cuidado. Terminamos teniendo subprocesos de trabajo para limitar demasiadas solicitudes utilizando un controlador http asíncrono, de lo contrario, la aplicación simplemente se abrumaría, se bloquearía y se quemaría. Significaba que se podía acumular una gran acumulación de pedidos, pero al menos el sitio se mantendría activo.

Echa un vistazo a TestComplete .

Secundo la sugerencia de opensta. Solo agregaría que le permite hacer cosas para monitorear el servidor que está probando usando SMTP. Hacemos un seguimiento de la carga del procesador, la memoria utilizada, los byes enviados, etc. El único inconveniente es que si encuentra algo bloqueado y desea solucionarlo, depende de varias bibliotecas de código abierto que ya no se mantienen, por lo que se obtiene una compilación La versión de la fuente es más complicada que con la mayoría de los OSS.

Jugué con JMeter. Uno piensa que no se pudo probar fue ASP.NET Webforms. El estado de vista rompió mis pruebas. No sé por qué, pero hay un par de herramientas que no manejan el estado de vista correctamente. Mi proyecto actual es ASP.NET MVC y JMeter funciona bien con él.

Tuve buenos resultados con FunkLoad :

• Interacción fácil con el usuario del script
• los informes son claros
• puede monitorear la carga del servidor

A riesgo de ser acusado de autopromoción desvergonzada, me gustaría señalar que en mi búsqueda de una herramienta de prueba de carga gratuita fui a este artículo: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

O no pude obtener el rendimiento que quería, o no pude obtener la flexibilidad que quería. Y quería agregar fácilmente los resultados de múltiples hosts de generación de prueba de carga en el análisis posterior a la prueba.

Probé todas las herramientas de la lista y, para mi frustración, descubrí que ninguna de ellas hizo lo que yo quería. Así que construí uno y lo estoy compartiendo.

Aquí está: http://sourceforge.net/projects/loadmonger

PD: No hay comentarios sarcásticos sobre el nombre de personas que están familiarizadas con la jerga urbana. No era, pero ahora soy un poco más mundano.

Yo también voto por jMeter y quiero agregar algunas citas a la respuesta de @PeterBernier.

La pregunta principal que responden las pruebas de carga es ¿cuántos usuarios concurrentes puede admitir mi aplicación web? Para obtener una respuesta adecuada, las pruebas de carga deben representar el uso real de la aplicación, lo más cerca posible .

Mantenga en cuenta lo anterior, jMeter tiene muchos bloques de construcción Controladores Lógicos , Config Elementos , Pre Procesadores , Oyentes , ... que puede ayudar en esto.

Puede imitar la situación del mundo real con jMeter, por ejemplo, puede:

1. Configurar jMeter para actuar como navegador real mediante la configuración ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Configurar jMeter para generar peticiones de los usuarios (por definir number of users per second, ramp-up time, scheduling, ...)
3. Configure muchos clientes con jMeter en ellos, para hacer una prueba de carga distribuida.
4. Procese la respuesta para encontrar si el servidor responde correctamente durante la prueba. (Por ejemplo, assertrespuesta para encontrar un texto en él)

Por favor considera:

• Es fácil comenzar una prueba de aplicación web real con jMeter en minutos. El jMeter tiene una herramienta muy fácil que registra su escenario de prueba (conocido como HTTP(S) Test Script Recorder).
• jMeter tiene muchos complementos en http://jmeter-plugins.org .
• La interfaz de usuario jMeter está basada en swing y ha realizado buenos cambios en jMeter 3.2. Por otro lado, tenga en cuenta que la GUI de JMeter solo debe usarse para pruebas y depuración. No es una buena práctica usarlo en modo GUI para la prueba real. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Configure y pruebe su escenario y ejecútelo en modo no gui.
• Hay muchos informes que muestran herramientas en jMeter (conocido como listeners) pero no están destinados a estar activados durante la prueba. Debe ejecutar su prueba y generar informes ( .jtlarchivos). Luego debe usar estas herramientas para analizar el resultado. Eche un vistazo a https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats o https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

El https://www.blazemeter.com/jmeter tiene información muy buena y práctica para ayudarle a configurar el entorno de prueba.