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

En el pasado, utilicé Microsoft Web Application Stress Tool y Pylot para probar las aplicaciones web de prueba. Escribí una página de inicio simple, una secuencia de comandos de inicio de sesión y una guía de sitio (en un sitio de comercio electrónico que agrega algunos artículos a un carrito y finaliza la compra).

Solo acceder a la página principal con un puñado de desarrolladores casi siempre ubicaría un problema importante. Aparecerían más problemas de escalabilidad en la segunda etapa, e incluso más, después del lanzamiento.

La URL de las herramientas que utilicé fue Microsoft Homer (también conocida como Herramienta de estrés de la aplicación web de Microsoft ) y Pylot .

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

¿Qué has hecho, qué herramientas has usado y qué éxito has tenido con tu enfoque? La parte que me resulta más interesante es encontrar algún tipo de fórmula significativa para calcular la cantidad de usuarios simultáneos que una aplicación puede admitir a partir de los números informados por la aplicación de prueba de estrés.

Aquí hay otra votación para JMeter .

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

Sin embargo, tiene una gran curva de aprendizaje una vez que comienzas a realizar pruebas complicadas, pero vale la pena. Puede ponerse en marcha rápidamente, y dependiendo de qué tipo de prueba de estrés desee hacer, podría estar bien.

Pros:

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

Contras:

  • La interfaz de usuario está escrita en Swing. (ugh!)
  • JMeter funciona al analizar 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 abrupta para los no progtwigdores. Si estás familiarizado con las expresiones regulares, ya estás adelantado al juego.
  • Hay una gran cantidad de idiotas ( inserte expletivos ) en el foro de soporte haciendo preguntas estúpidas que podrían resolverse fácilmente si le dieran a la documentación una mirada superficial. (‘¿Cómo uso JMeter para poner a prueba mi GUI de Windows’ se muestra con bastante frecuencia).
  • Informar “de fábrica” ​​deja mucho que desear, particularmente para pruebas más grandes. En la prueba que mencioné anteriormente, terminé escribiendo una aplicación de consola rápida para hacer algunas de las conversiones ‘xml-logfile’ a ‘html’. Eso fue hace unos años, por lo que es probable que esto 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, por lo que no creemos que sea una herramienta solo de Java (por su naturaleza, cualquier herramienta de estrés web no debe vincularse a la plataforma que utiliza).

Hicimos algunas cosas buenas con eso … éramos una aplicación de telecomunicaciones basada en web, así que un buen uso que preparé 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 básicamente era 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 modificado para que solo recoja las 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 mantuvo nuestra aplicación con mucha carga, y fue muy efectiva para encontrar cuellos de botella. La herramienta ha incorporado informes para mostrar cuánto tardan las solicitudes, pero nunca las usamos. Los registros también pueden almacenar todas las respuestas y otras cosas, o el registro personalizado.

Recomiendo esta herramienta, muy útil por el precio … pero espero hacer alguna configuración personalizada con ella (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 de código abierto que existe. Es simple de usar y es trabajado activamente por un tipo genial ( Corey Goldberg ). Como fundador de OpenQA , también me complace que Pylot ahora figure en nuestra página de inicio y use parte de nuestra infraestructura (concretamente los foros).

Sin embargo, también recientemente decidí que todo el concepto de pruebas de carga era defectuoso: la emulación del tráfico HTTP, con aplicaciones tan complejas como se han convertido, es un problema en el trasero. Es por eso que creé la herramienta comercial BrowserMob. Es un servicio de prueba de carga externo que usa Selenium para controlar navegadores web reales cuando se reproduce la carga.

El enfoque obviamente requiere mucho más hardware que las técnicas normales de prueba de carga, pero el hardware es realmente 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 es necesario hacer ninguna coincidencia de expresiones regulares avanzada (como requiere JMeter) para extraer las cookies, el estado de sesión .NET, los parámetros de solicitud de Ajax, etc. Ya que estás usando navegadores reales, simplemente hacen lo que se supone que deben hacer.

Lamento lanzar descaradamente un producto comercial, pero espero que el concepto sea interesante para algunas personas y al menos las 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 puedes probar el backend de la base de datos, los servicios de mensajería y los servidores de correo electrónico.

ab , sitio , tsung , httperf , arrolla, pilón, request-log-analyzer , perftools

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

ambos son simples de comenzar:

ab -cn -t 30 url siege -b -cn -t 30s url 

el sitio puede funcionar con más urls.

la última versión de asedio se vuelve detallada en siegerc, lo cual es molesto. solo puede deshabilitarlo editando ese archivo ( /usr/local/etc/siegerc ).

Para un servicio basado en web, echa un vistazo a loader.io .

Resumen:

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

También tienen una API .

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

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

Aquí están mis pensamientos:

Jmeter vs Grinder

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

Grinder utiliza el scripting Jython dentro de un framework Java muti-threaded, por lo que está más orientado a los progtwigdores.

Ambas herramientas manejarán HTTP y HTTPS y tendrán una grabadora proxy para que pueda comenzar. Ambas herramientas usan el modelo de controlador para controlar múltiples agentes de prueba, por lo que la escalabilidad no es un problema (dado el acceso a la nube).

Cual es mejor:-

Una llamada difícil ya que la curva de aprendizaje es abrupta con ambas herramientas a medida que ingresas a los requisitos de scripting 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 que vuelven por primera vez (manipulando 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 llegas a un ‘bloque de carreteras’, es algo que no puedes ‘hacer’ fácilmente con Jmeter y luego echar un vistazo a Grinder. La buena noticia es que estas herramientas tienen el mismo requisito de Java y no se descarta una solución de “combinación y combinación”.

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

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

De la experiencia, alrededor de 25 instancias de ‘navegadores sin cabeza’ se pueden ejecutar 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 los scripts de prueba funcionales para convertirse en scripts de prueba de rendimiento.

La escalabilidad se ve comprometida ya que se necesitarán más VM para manejar la carga, en comparación con un controlador HTTP como el Grinder o el Jmeter. Dicho esto, si desea administrar 500 usuarios virtuales, entonces con 20 instancias de Amazon Small (6 centavos por hora cada uno) a un costo de tan solo $ 1.20 por hora, obtendrá una carga que se acerca mucho a la experiencia real del usuario.

Además, existe un impresionante marco open-source de python puro distribuido y escalable que usa greenlets . Es excelente para simular una gran 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 de Jmeter Threading
  • DSL Scala que es muy fácil de mantener en comparación con Jmeter XML
  • Fácil de escribir las pruebas, no asustar 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, puedes hacerlo lo más complicado posible. Una de las características que se destacan por Gatling es informar que es muy detallado.

Aquí hay algunos enlaces:
Gatling
Gatling Tutorial

Recientemente di una charla sobre eso, puedes ir a 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 soluciones más nuevas son dignas de mención. Checkout LoadImpact: http://www.loadimpact.com .

Intenté WebLoad es una herramienta bastante ordenada. Viene con el 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 estrés en su servidor web. Pruébalo, lo recomiendo.

Probando todo lo mencionado aquí, encontré que el cargador de curl es el mejor para mis propósitos. Interfaz muy fácil, monitoreo en tiempo real, estadísticas útiles, a partir de las cuales construyo gráficos de desempeño. Todas las características de libcurl están incluidas.

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

  • Extensión de BlazeMeter Chrome
  • Entrada de blog sobre eso

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 buscas otra forma de evaluación comparativa de 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 está afiliado). Acabo de recibir este enlace en 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 suene extraño, pero buena suerte presionando y frenando su servicio 🙂

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

He usado openSTA .

Esto permite que una sesión con un sitio web sea grabada y luego reproducida a través de un lenguaje de script relativamente simple.

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

Le permite juntar 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 progtwigr 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 estrés de la aplicación web de Microsoft. Es la herramienta más fácil que he usado. Es limitado de muchas maneras, incluyendo solo poder llegar al puerto 80 en pruebas creadas manualmente. Pero, su facilidad de uso significa que realmente se usa.

Complementamos la carga de esta herramienta con otras herramientas, incluidas OpenSTA y arañas de comprobació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 para lanzar.

Sugiero abrir otra pregunta con respecto a la interpretación de los resultados de la herramienta de estrés MS.

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

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

La otra ventaja es que con el proyecto de 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 disponible.

Sin embargo, se requiere una licencia separada y costosa para usar varias máquinas para cargar la prueba 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 dices, dejarlo hasta el final del proyecto tiende a llevar a la decepción …

Por lo tanto, durante el desarrollo, incluimos pruebas multiusuario muy básicas (usando selenium), que comprueban la locura básica, como la administración de sesión interrumpida, problemas obvios de simultaneidad 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 extremo, incluimos pruebas de rendimiento básicas en nuestras pruebas; por lo general, establecemos las pruebas con BadBoy y las importamos a JMeter, reemplazando los detalles de inicio de sesión y otras cosas específicas de la secuencia. A continuación, aumentamos estas al nivel que el servidor está tratando con 100 solicitudes por segundo; si el tiempo de respuesta es inferior a 1 segundo, eso suele ser suficiente. Lanzamos y seguimos con nuestras vidas.

Para proyectos con requisitos de rendimiento extremo, todavía utilizamos BadBoy y JMeter, pero invertimos mucha energía en comprender los cuellos de botella en los servidores de nuestra plataforma 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 que es tan rápida como puede ser en “1 servidor web, 1 servidor de base de datos”. Por lo general, nos desplegamos en nuestra infraestructura objective y usamos uno de los servicios “Jmeter en la nube” para volver a ejecutar las pruebas a escala.

Nuevamente, 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 ejecute sus pruebas de estrés, sino también que recopile la información que necesita para comprender el rendimiento de su aplicación.

Aquí se mencionan muchas buenas herramientas. Me pregunto si las herramientas son una respuesta a la pregunta: “¿Cómo se prueba 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 estrés muestran cómo falla una aplicación web al responder a una creciente población de usuarios. Las pruebas de estrés 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 corte en mayo de 2011, no se pudo iniciar sesión en la aplicación web de Pepsi.com. La aplicación no falló completamente, solo una gran parte de su función normal dejó de estar disponible para los usuarios.

Las pruebas de rendimiento muestran la capacidad de una aplicación web para mantener los tiempos de respuesta independientemente de la cantidad de usuarios que utilizan simultáneamente la aplicación. Por ejemplo, una aplicación que maneja 10 transacciones por segundo con 10 usuarios simultáneos 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 una escalabilidad lineal.

Además, en el ejemplo anterior, el recuento de transacción por segundo debe ser solo de operaciones exitosas de un caso de uso de prueba / flujo de trabajo. Las fallas generalmente ocurren en tiempos más cortos y harán que la medición del 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 de secuencias de comandos sin cabeza PhantomJS / CasperJs para probar sitios web. Phantomjs analizará y renderizará cada página, ejecutará el script del lado del cliente. El enfoque del navegador sin cabeza es más fácil de escribir escenarios de prueba para soportar la compleja aplicación AJAX Web 2.0, la navegación del navegador, el clic del mouse y las pulsaciones de teclado en el navegador o esperar hasta que exista un elemento en DOM. LoadBooster admite secuencias de comandos HTML de selenium.

Descargo de responsabilidad: yo 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 se puede usar para ejecutar rápidamente pruebas usando 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 lockings … así que la moraleja era pensar cuidadosamente sobre el esquema de locking. Terminamos teniendo subprocesos de trabajo para estrangular demasiadas solicitudes usando un manejador de http asincrónico, de lo contrario, la aplicación quedaría abrumada y colapsaría y se quemaría. Significaba que se acumularía un gran retraso, pero al menos el sitio se mantendría.

Eche un vistazo a TestComplete .

Apoyo 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, byes enviados, etc. El único inconveniente es que si encuentra algo boken y quiere hacer una corrección, se basa en varias bibliotecas de código abierto que ya no se mantienen, por lo que obtener una comstackción la versión de la fuente es más complicada que con la mayoría de OSS.

Jugué con JMeter. Uno piensa que no podría no probar era ASP.NET Webforms. The viewstate rompió mis pruebas. No estoy seguro por qué, pero hay un par de herramientas que no manejan ViewState correctamente. Mi proyecto actual es ASP.NET MVC y JMeter funciona bien con él.

Obtuve buenos resultados con FunkLoad :

  • fácil de guiar la interacción del usuario
  • 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 bien no podía obtener el rendimiento que quería, o no podía obtener la flexibilidad que quería. Y quería agregar fácilmente los resultados de varios 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 hacer. 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 lo era, pero soy un poco más mundano ahora.

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

La pregunta principal que responde la prueba de carga es ¿cuántos usuarios simultáneos 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 .

Tenga en cuenta lo anterior, jMeter tiene muchos bloques de construcción Controladores lógicos , Elementos de configuración , Pre procesadores , Oyentes , … que pueden ayudarlo en esto.

Puedes imitar la situación del mundo real con jMeter, por ejemplo, puedes:

  1. Configure jMeter para que actúe como navegador real configurando ( concurrent resource download , browser cache , http headers , setting request time out , cookie management , https support , encoding , ajax support , …)
  2. Configure jMeter para generar solicitudes de usuario (definiendo el number of users per second , ramp-up time scheduling , scheduling , …)
  3. Configure muchos clientes con jMeter en ellos, para hacer una prueba de carga distribuida.
  4. Procesar la respuesta para encontrar si el servidor está respondiendo correctamente durante la prueba. (Por ejemplo, assert respuesta para encontrar un texto en ella)

Por favor considera:

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