Hablar de JMeter? Lo más probable es que si está en el tema, ya haya leído todo sobre esta herramienta para pruebas de estrés. Pero tengo algo para sorprenderte. Durante tres años en QA, me di cuenta de que JMeter es muy versátil y puede usarse para una variedad de propósitos. Por ejemplo, para:
- buscar un error esquivo con la caída del sitio para algunos usuarios;
- calentamiento rápido de caché en miles de páginas de productos;
- probar el backend de una aplicación móvil;
- crear 2000 registros con datos de usuario en la base de datos de la aplicación en poco tiempo.
Si estás interesado, bienvenido a cat. Resultó voluminoso, así que dividiré el artículo en dos partes.
Descargo de responsabilidad: por razones obvias, no inserto capturas de pantalla de proyectos reales en el artículo (ni extraigo toda la información importante de ellos). Las ilustraciones se proporcionan únicamente con fines educativos y de investigación.
Aplicación clásica de JMeter
JMeter: applet de Java con GUI. Para las pruebas, comienza sin una interfaz gráfica. Y para escribir guiones de prueba, tiene un panel en el que puedes hacer cualquier cosa.
Así es como se ve el proceso de creación del guión (aquí incluso la palabra "escritura" no encaja)Se crea un plan de prueba común, en el que Thread Group se lanza con los elementos principales de la prueba: controladores de proceso y solicitudes (HTTP, FTP, etc.).
Además, hay elementos adicionales para configurar los parámetros. Por ejemplo, HTTP Request Defaults le permite especificar el servidor principal, los encabezados y habilitar / deshabilitar la descarga de activos adicionales (imágenes, estilos, fuentes, etc.). Es fácil resolverlo. Y puede ejecutar inmediatamente una prueba desde esta interfaz y ver los resultados.
JMeter puede registrar tales casos de prueba. Se ejecuta como un proxy en la máquina local y, si configura un navegador (o aplicación), genera tráfico a través de este proxy, JMeter registrará todas las solicitudes y respuestas. Y a partir de este conjunto, puede inventar un script de prueba que repita las acciones del usuario y ejecutarlo donde y cuando quiera:
El principal problema es el montón de memoria de Java en sí. Se apoya en el techo y puede caer con 50 hilos de pruebas simultáneas, incluso en máquinas de gama alta.
Si la máquina no tiene suficiente energía para una prueba de carga completa, comuníquese con una organización de terceros. Implementaron una infraestructura que es un conjunto de servidores. Tienen el mismo JMeter. Por una tarifa, estos chicos ejecutarán su script en cualquier carga. Solicitamos dichos servicios en Octoperf y Blazemeter.
Esto es fútbol, bebé: cómo detectamos un error con un bloqueo parcial del servidor
Hemos estado involucrados en el desarrollo web durante 18 años (aplausos, ahora puedes fumar, casarte y ver a John Wick). Ha habido muchos clientes en su vida, pero los más grandes han aparecido recientemente. Por ejemplo, creamos un sitio en
Sitecore para uno de los clubes de fútbol de la Premier League inglesa con el paradigma SPW (sitio web de una sola página: todas las páginas se abren sin volver a cargar la página del navegador). Debajo del capó está el panel de administración para administrar una página de partidos en vivo. Esta es una transmisión textual en línea del juego: los eventos principales (goles, eliminaciones, tiros libres) se cargan automáticamente desde el sistema Opta, y las fotos, comentarios y reposts de los fanáticos de Twitter e Instagram son publicados por personas en vivo, administradores de contenido de clubes de fútbol.
Notaré con orgullo: después del lanzamiento, los medios de comunicación británicos publicaron artículos bajo los encabezados como "Finalmente, la hegemonía de los antiguos sitios de clubes de fútbol ha terminado". En ese momento, la mayoría de los clubes ya tenían sitios. Pero parecía que se desarrollaron a principios de la década de 2000 y no han cambiado desde entonces, con el diseño y la experiencia de usuario correspondientes.
Antes del lanzamiento, realizamos una prueba de carga completa y nos aseguramos de que todo funcione como debería. La estructura del servidor se veía así:
- la solicitud del cliente va al servidor de equilibrio de carga →
- el servidor de equilibrio de carga verifica el estado de ocho servidores de CD →
- el servidor de equilibrio de carga envía una solicitud al servidor de CD menos cargado →
- El servidor de CD responde al cliente.
Un año después del lanzamiento, durante una gran afluencia de usuarios al sitio, el cliente llamó y dijo que el sitio estaba caído:
- Nuestro sitio no funciona! ¡No funciona en absoluto! ¡Solo una pantalla blanca y una inscripción del navegador que indica que el sitio no funciona! - dice el cliente
Estamos en pánico al abrir el sitio, y con él todo está bien:
"Todavía funciona", respondemos.
El cliente abre el sitio desde el teléfono y la computadora y ... ¡todo está bien también!
- De verdad, lo siento. Aparentemente, los usuarios tienen problemas.
Tales mensajes no aparecen desde cero, por lo que realizamos un estudio: lanzamos una utilidad para monitorear el estado de los servidores de Densidad del servidor y observamos lo que les sucede durante la afluencia de usuarios en el sitio:
Hay una carga, pero todos los servidores de CD tienen el mismo aspecto e inclusoPronto la historia se repitió: algunos usuarios informaron un sitio completamente roto. No se trataba de algún tipo de error o página no encontrada: el servidor simplemente no respondió a la solicitud. Fue posible detectar la situación con la ayuda de JMeter.
El objetivo era simple: cargar los ocho servidores y ver qué sucede. Se llevó a cabo una prueba de esfuerzo cuando estaba amaneciendo en Chelyabinsk, y en Londres era una noche profunda. Utilizamos varias máquinas en modo sin interfaz (le permite ejecutar muchos más hilos al mismo tiempo). El script abrió sin cesar la página de inicio, y este fue nuestro principal error.
Descargamos los mismos activos que ya estaban almacenados en caché cien veces. Por lo tanto, la carga salió insignificante. Entonces surgió la idea: en el sitio: un carro y un pequeño carrito de páginas con noticias para ciertas fechas. Si avanza un par de variables y las sustituye en la URL, siempre obtendremos una página aleatoria (por ejemplo, ... url / news / 2016/08/23 /? Page = 4).
De repente, nos dimos cuenta de que la Densidad del servidor tiene un "suavizado" incorporado en los gráficos de la carga del servidor durante los últimos períodos. Si en cinco minutos la carga en el servidor alcanzó el 100%, luego cayó al 0%, y después de 20-30 segundos aumentó al 90%, mostrará el valor promedio para este período, aproximadamente 80-90%. Por lo tanto, no vimos un bloqueo real del servidor.
Después de examinar los registros en detalle durante las pruebas de estrés, descubrimos que uno de los servidores de CD se reinició con una carga del 100% y no se lo contó a nadie (esto es muy introvertido).
El equilibrador de carga solo observó la utilización de la CPU de todos los servidores. Vio que uno de ellos estaba cargado al 20%, y el resto al 90%, y envió al usuario al primero. Y él estaba reiniciando y le dio una pantalla blanca. Además, el servidor de distribución expuso al usuario a una cookie y lo unió estrechamente al servidor inactivo. Por lo tanto, incluso después de la actualización, el sitio no estaba disponible. Los 7 usuarios restantes de 8 al mismo tiempo disfrutaron de la vida y dijeron que todo funciona.
Conclusión
descubrimos que JMeter se puede usar para pruebas de estrés y al mismo tiempo para analizar el estado de los servidores durante las pruebas con otras herramientas. Logramos “captar” el problema con la caída del sitio entre algunos usuarios y resolverlo corrigiendo la lógica de distribución de carga y agregando control de estado.
En la siguiente parte, le contaré cómo, con la ayuda de JMeter, configuramos el proceso de almacenamiento en caché de las páginas de productos, probamos el funcionamiento de una aplicación móvil sin la aplicación en sí y creamos 2000 usuarios en el sistema sin acceso a la base de datos.