100: Azure Load Testing, Azure Chaos Studio y JMeter”. Espero poder aportarte los conocimientos mínimos y necesarios para que puedas iniciarte en este apasionante mundo. Jose María Flores Zazo, autor
nos soliciten estas pruebas tengamos un recorrido suficiente para que podamos reaccionar instantáneamente. ¿Test de rendimiento? • Mejoras en el rendimiento = mejor resultado final. • El rendimiento mejorado = mejor uso y eficiente de los recursos. • Los usuarios de la web son muy exigentes. Quieren respuestas rápidas y períodos de espera muy cortos. • Un sitio web lento incide negativamente en los ingresos de una organización. JMeter Herramienta líder, sin licencias restrictivas, con ficheros que podemos importar/exportar y Open Source. Y lo más importante: es el formato admitido por Azure Load Testing. Existen otras opciones • K6: https://k6.io/ • Gatlin: https://gatling.io/ • WebLOAD de https://www.radview.com/ • Y varias más como Vegeta, etc. etc. ¿No es importante? – ¿Cuantes veces lo has podido escuchar? … en muchas organizaciones las pruebas nos son prioritarias hasta que se vuelven críticas …
general de las pruebas de rendimiento: • Las pruebas de rendimiento se realizan en un sistema o aplicación para medir atributos como el tiempo de respuesta, el rendimiento, escalabilidad, etc. A estos atributos se les conoce como criterios de rendimiento. • Existen muchos tipos de pruebas y cada una de ella requiere diferentes criterios. Dependiendo de la naturaleza de la aplicación, algunos criterios son más importantes que otros. • Las pruebas de rendimiento son diferentes a las funcionales. Nos centramos principalmente en la velocidad, mientras que las funcionales se centran en el comportamiento de la aplicación. • Los resultados de las pruebas de rendimiento deben interpretarse después de que la aplicación pase las pruebas funcionales. Esta práctica va desde como poder usar JMeter hasta como integrarlo en el ciclo de DevOps. En unos clientes podrás quedarte con un perfil de QA o un desarrollador que se responsabilice de ejecutar las pruebas sin incluirlas en DevOps, es decir de forma manual, hasta aquellos en los que el ciclo debe ser completamente automatizado. Atributos – Las pruebas de rendimiento miden atributos Load Tests Security Tests GUI Tests API Tests Integration Tests Component Tests Unit Tests + + - - Cantidad de Tests Coste Tiempo Ejecución
tiempo que arda la aplicación en responder a una solicitud de usuario. • Se mi de en segundos o milisegundos, según corresponda a la aplicación. • Cada aplicación debe intentar minimizar el tiempo de repuesta. Términos relacionados: • Tiempo de respuesta absoluto: tiempo total transcurrido desde el instante en que un usuario hace clic en un enlace o envía un formulario hasta que la respuesta del servidor se procesa por completo. • Tiempo de respuesta percibido: tiempo de respuesta absoluto para algunas páginas web complejas puede ser inaceptablemente alto. Para resolver el problema lo habitual es usar la solicitud/respuesta progresiva. • Tiempo de procesamiento del servidor: el tiempo que tardar el servidor en procesar la entrada y generar la salida. Entran factores como hardware, carga del sistema o complejidad de la solicitud. • Tiempo de renderizado: relacionado con el navegador, dispositivo del usuario, presencia multimedia/JavaScript, etc. Es el tiempo que tarda el navegador en analizar y renderizar la respuesta del servidor. • Latencia de red: es le tiempo de ida y vuelta que tarda un paquete de datos en viajar por la red al servidor y viceversa. No se incluye el tiempo de proseado en servidor y tiempo de renderizado. Varia debido a la localización del usuario, hora del día y carga de la red Conceptos – Nos ayudan a hablar con propiedad Browser Web App Response Time Server Processing Time Network Latency
constituye una transacción. • El número de transacciones por unidad de tiempo, se denomina rendimiento. • Se mide en transacciones / segundo o ancho de banda (bytes/segundo). • Depende del hardware del servidor, la carga del sistema y la latencia de la red. • La aplicación debe esforzarse para maximizar el rendimiento. Utilización • La relación entre el rendimiento de la aplicación y su capacidad máxima. • Es una medida que nos dice “lo bien” que se está usando la aplicación. • No es deseable operar por encima del 80% de la utilización porque las solicitudes del usuario no llegan de manera uniforme y el sistema debería poder manejar un pico de carga. Robustez • Esta es una medida que nos indica lo bien que nuestra aplicación detecta y maneja varios errores y excepciones. • Si el sistema falla o deja de estar disponible, la marca y la reputación de la empresa se ponen en entredicho. • El tiempo medio entre fallos (Mean Time between failures – MTbF) es una métrica muy utilizada para este propósito.
un sistema puede expandir su capacidad cuando se agregan recursos adicionales. • Idealmente, la capacidad del sistema aumentará linealmente a medida que se agreguen recursos adicionales. Sin embargo, esto rara vez se logra en la práctica. Es una buena medida conocer los recursos que se necesitarían para que el sistema pueda manejar la carga futura proyectada. • La escalabilidad vertical se logra actualizando el hardware. Por ejemplo: más memoria, disco duro, una mejor CPU o CPUs adicionales. • La escalabilidad horizontal se obtiene agregando servidores al clúster. Por ejemplo, más servidores web y servidores de aplicaciones en una granja o clúster web. Percepción del usuario El usuario es el juez supremo del rendimiento. El usuario tiene una expectativa establecida con respecto al tiempo de respuesta y robustez. Si se trata de un sitio web de noticias de entretenimiento, 6 segundos de respuesta, se puede admitir, pero si se trata de una web que opera en bolsa, necesitamos una respuesta inferior a 1 segundo. El ajuste de rendimiento se realizar si el rendimiento medio es inferior al esperado para esa categoría de aplicación. Por tanto, debemos reestructurar para mejorar la percepción del usuario frente a solicitud/respuesta . Coste El sistema debería consumir menos recursos y ahorrar dinero al cliente. La utilización del rendimiento son alguna de las medidas que influyen en el coste.
usa de forma muy laxa y puede referirse a diferentes tipos de pruebas. Además, la distinción entre tipos de pruebas de rendimiento habitualmente es un término del cual no damos una definición exacta. Por tanto, lleva a mayor confusión a nuestros clientes. Razón de más para que incluyas en la documentación que tipos de test vas a realizar junto a su definición. Las cosas claras desde el principio. Test de estrés o esfuerzo Es una especia de prueba de rendimiento que prueba la aplicación más allá de los límites normales. La aplicación se somete a una carga excesiva y luego se estudia su estabilidad y rendimiento. Este tipo de pruebas se utiliza para determinar cómo responde la aplicación a los picos de carga. Aclaración: ten en cuenta que la prueba de rendimiento evalúa y miden la aplicación bajo una carga normal esperada. El estrés somete la aplicación a cargas que superan la normalidad con creces. Test de carga Es una prueba de rendimiento que se realiza a nivel de carga especificado. Es decir, idealmente debemos realizar pruebas de carga con diferentes niveles de carga para observar el comportamiento de la aplicación. Las cosas claras – Incluye definiciones de test en la documentación
realiza una prueba de carga máxima a la carga esperada que soporte la aplicación. Por ejemplo, los sitios web de comercio electrónico experimentan un pico de trafico durante el Black Friday, el Cyber Monday y las Navidades. Por tanto, una prueba de carga máxima en ese caso probaría la aplicación dentro de las especificaciones de carga, pero en el extremo superior. Aclaración: una prueba de estrés va más allá de la carga máxima. Test de resistencia (soak) También conocidas como remojo (soak). La aplicación se somete a una carga específica que esta dentro del límite especificado, pero durante un período prolongado. Se realiza durante muchas horas seguidas. Esta misma prueba determina si la aplicación está utilizando los recursos correctamente. Esta prueba revelará el siguiente tipo de problemas: memory leaks, datababe connection exhaustion, network connection exhaustion, archivos de registro (log) llenos, rotación de registro y agotamiento de otros recursos. Test de escalabilidad Cuando una aplicación web se convierte en un éxito experimentan un crecimiento masivo, a veces exponencial. Por tanto, es aconsejable medir la escala de la aplicación. La escalabilidad se define como lo bien que se comporta la aplicación con un aumento de carga sin dejar de cumplir con los criterios de rendimiento deseados. Una prueba de escalabilidad aumentaría los recursos y probaría si la aplicación proporciona o no un aumento en capacidad. Idealmente, esperamos que sea lineal (su duplico el hardware debería tener el doble de capacidad).
capacidad es una prueba de carga que establece la carga máxima que la aplicación puede manjar mientras cumple con los criterios de desempeño. La métrica resultante se llamada capacidad máxima. Se utiliza para escalar la aplicación y estimar los costos para su crecimiento futuro. Test de picos y capacidad de ráfaga Una prueba de picos es una prueba de carga en la que la aplicación se somete a breves períodos de aumento repentino de la carga, una pequeña fracción más allá de la capacidad máxima. Por lo general, se hace para estimar la debilidad/fortaleza de una aplicación. Se espera que la aplicación sea sólida y continúe cumpliendo con los criterios de rendimiento durante el pico. Esta métrica se llama capacidad de ráfaga (burst). Test de humo de rendimiento Se prueban juntos algunos casos de uso comunes y esenciales junto con casos de uso relacionados con el código sujeto a cambio. Solo cuando una prueba de humo tiene éxito, se lleva a cabo el conjunto de pruebas de rendimiento. Si la prueba de humo falla, no se realizan más pruebas de funcionamiento hasta que se haya rectificado el defecto de funcionamiento.
fail-over La infraestructura de la aplicación web moderna está diseñada para que tenga alta disponibilidad y resista a fallas de hardware/software. Idealmente, la arquitectura debe garantizar que no exista falla y que haya servidores a la espera para asumir el control de forma transparente sin afectar a la experiencia del usuario. Con esta prueba se simulan fallos de hardware y software, con test de rendimiento relevantes para verificar que la aplicación sigue cumpliendo los requisitos de rendimiento. UN EJÉRCITO DE SIMIOS AL SERVICIO DE NETFLIX Muy conocido es el caso de Netflix: “Chaos Engineering Upgrade” (https://netflixtechblog.com/chaos-engineering-upgraded-878d341f15fa): Chaos Monkey: deshabilita aleatoriamente las instancias de producción para asegurarse de que el sistema puede sobrevivir a este tipo de falla sin ningún impacto en el cliente. Chaos Gorilla: similar al anterior, pero simula la interrupción de toda una zona de disponibilidad de Amazon. Verifica que los servicios automáticamente se balanceen con las zonas de disponibilidad operativas sin impacto visible en el usuario o requieran una intervención manual. Chaos Kong in Operations, es muy raro que AWS tenga una caída mundial de un servicio en todas las regiones, pero sucedió en 2015 con DynamoDB . Y gracias a este ejercicio de Chaos Kong el impacto fue mínimo, podéis leer más en el link anterior.
simular situaciones de caos y estrés en el sistema con el fin de detectar posibles fallos y debilidades en el mismo. El objetivo de esta técnica es evaluar la capacidad del software para recuperarse y mantenerse en funcionamiento en situaciones inesperadas y extremas. Para realizar pruebas de caos, se pueden utilizar diferentes técnicas y herramientas que generen situaciones aleatorias, como la interrupción de servicios, la generación de errores, la sobrecarga de tráfico, entre otros. Estas pruebas se realizan en entornos controlados y monitoreados para garantizar que el software no se dañe permanentemente durante la prueba. El Chaos Testing se ha convertido en una práctica cada vez más popular en los entornos de desarrollo de software, especialmente en sistemas distribuidos y en la nube, donde los sistemas son más complejos y están expuestos a mayores niveles de riesgo. A través de estas pruebas, se pueden identificar y corregir problemas en el software antes de que se produzcan en producción, lo que ayuda a mejorar la calidad y la fiabilidad del sistema. Es posible que en algunos sitios veas ingeniería del caos. En cualquier caso el uso de este término probablemente se refiera a la aplicación de conceptos relacionados con el caos en el diseño y control de sistemas dinámicos complejos. Chaos Testing – Redibujando la pirámide del testing GUI Tests API Tests Integration Tests Component Tests Unit Tests + + - - Cantidad de Tests Coste Tiempo Ejecución Chaos Test Load Tests Security Tests Chaos Testing(1/2) Introducción
razones para aplicar este tipo de test: • Determinar el riesgo y el coste, establecer indicadores de nivel de servicio, objetivos y acuerdos (SLIs, SLOs y SLAs). • Probar un sistema (a menudo complejo y distribuido) en su conjunto. • Descubrir propiedades emergentes de las que no se era consciente. Los pasos que nos conducen a la ingeniería del caos 1. Garantizar la observabilidad. 2. Definir un estado estacionario. 3. Formular una hipótesis. 4. Realiza el experimento y demuestra (o refuta) tu hipótesis. Es única en su especie La ingeniería del caos es una disciplina única que puede ser aplicada a sistemas de producción, pero no se limita exclusivamente a ese ámbito. Aunque gran parte del contenido en Internet se centra en "romper cosas en producción", esto no es el único enfoque de la ingeniería del caos, ni siquiera su objetivo principal y no sustituye a otros métodos de pruebas, como las de integración o unitarias; es un complemento. No existen recetas que aplicar ya que su implementación dependerá del escenario en conjunto en el que te encuentres. Chaos Testing(2/2) Introducción
de software que tienen objetivos diferentes. • El performance testing se enfoca en medir y evaluar el rendimiento del sistema en condiciones normales y predecibles de carga. El objetivo es determinar la capacidad del sistema para manejar una cantidad determinada de usuarios, transacciones, consultas o cualquier otro tipo de actividad esperada. Las pruebas de rendimiento también pueden identificar cuellos de botella, tiempos de respuesta y otros indicadores de desempeño que afectan la experiencia del usuario. • Por otro lado, el chaos testing se enfoca en evaluar la capacidad del sistema para mantenerse estable y operativo en situaciones impredecibles y extremas, como fallas de infraestructura, interrupciones de red, caídas de servicios externos o cualquier otro tipo de evento no anticipado. El objetivo es descubrir fallas o debilidades en el sistema que puedan poner en peligro su estabilidad, confiabilidad o disponibilidad en situaciones críticas. En resumen, el performance testing se enfoca en medir y mejorar el rendimiento del sistema bajo condiciones controladas, mientras que el chaos testing se enfoca en descubrir y mitigar riesgos en situaciones impredecibles y extremas que pueden afectar la disponibilidad y estabilidad del sistema. Ambos tipos de pruebas son importantes y complementarios para garantizar la calidad y confiabilidad del software. Una vez visto esto, continuamos con el propositivo de este libro que no es otro que el trabajo con performance testing. Diferencias – No son lo mismo, no se usan para lo mismo Performance Testing vs Chaos Testing Introducción
que utilizamos para las pruebas de rendimiento se denomina entorno de prueba de rendimiento. Por lo general, está separado del entorno de producción. Aunque no es recomendable, a veces las pruebas de rendimiento se realizan en el propio entorno productivo. Las pruebas deben realizarse en un entorno independiente, pueden afectar de forma negativa a la experiencia del usuario. Las pruebas de carga de rendimiento pueden: • Bloquear el sistema. • Degradar el tiempo de respuesta de la aplicación. • Crear agujeros de seguridad debido al uso de cuentas de prueba. • Llenar las bases de datos de producción con datos de I/O de las pruebas de rendimiento. • Saturar las bases de datos, los logs de aplicación y los de sistema. • Afectar a la analítica. A largo plazo, es aconsejable tener un entorno de rendimiento dedicado, ya que evitarán estos errores y proporcionará el beneficio de la integración continua. Algunas empresas incluso tienen más de uno. Gracias a la nube estos entornos se aprovisionan a muy bajo coste. Independencia – La necesidad de un entorno de rendimiento independiente
del proceso de construcción del software para detectar cualquier defecto de rendimiento introducido como resultado de los cambios de software, de este modo el software madura junto a las pruebas de rendimiento. A pesar de los beneficios de un entorno de pruebas de rendimiento, a veces las pruebas de rendimiento se realizan en producción porque es prohibitivamente caro duplicar el entorno de producción en termino de hardware, licencias de software y servicios de terceros. El entorno de rendimiento debe modelarse según el entorno de producción. En un escenario ideal, el entorno de rendimiento debería ser una réplica del entorno de producción en términos de hardware, software, red, componentes y topología. Sin embargo, debido al presupuesto y otras limitaciones, esto puede que no sea posible. En tales casos, el entorno de rendimiento debe imitar el entorno de producción en todos sus aspectos claves. Habrá que hacer algunos compromisos lógicos, como, por ejemplo, en lugar de cuatro servidores web, optamos por dos; una sola instancia de la base de datos en lugar de la implementación master/slave de producción. Pero en ningún caso optar por la estrategia que nos permite la nube: montar un servicio web de menor potencia en CPU o RAM, por qué dependiendo del atributo a medir, impediría que extrapolásemos a n servidores, los datos no serían fehacientes.
ser aislado Debe estar en una subnet diferente, aislada de la de producción, para que cualquier actividad de la subnet no influya en producción o viceversa. Es evidente que en la nube esto se debe extender a su ecosistema: si usamos serverless sin subnet, pues este requisito queda anulado por definición. Herramientas de prueba de rendimiento Estas herramientas deben abordar la generación de carga, recopilación de datos, análisis y generación de informes. Las herramientas deben identificarse y sus características o uso específico deben extrapolarse y documentarse con suficiente antelación. No debería, idealmente hablando, introducirse en una fase tardía debido a que no estaríamos desarrollando de la mano al rendimiento y esto puede provocar que no podamos abordar un cambio debido al coste que supone cambiar piezas o arquitecturas en fases tardías. Por tanto, cuando antes mejor, es una fase más del desarrollo de un producto.
debe definir los requisitos y objetivos de desempeño, así como el enfoque para lograrlos y mantenerlos. Debe contener la política y la metodología de las pruebas de rendimiento. Ese documento debe ser un compromiso que refleje los objetivos de los responsables de IT y negocio. Requisitos de desempeño Existen muchos requisitos de rendimiento dentro de la industria. Si bien todos los requisitos podrían ser útiles, solo un subconjunto es aplicable en un momento dado y un número menor será de importancia crítica debido a obligaciones contractuales, acuerdos de SLA o estipulaciones del owner de la aplicación. Aquellos que finalmente identifiquemos serán los denominados requisitos de desempeño. Por ejemplo, para una aplicación de acciones de bolsa, un tiempo de 1 segundo es un requisito. Cada release debe cumplir con este requisito. Objetivos de desempeño Son criterios deseados, pero no críticos. Suelen estar determinados por el rendimiento de aplicaciones similares de la competencia. El logro de estos objetivos sería una ventaja para esta empresa. Por ejemplo, para un sitio de noticias puede ser deseable que el tiempo de respuesta sea de 6 segundos. Aclaración: debes tener en cuenta que los requisitos son estrictos y han de cumplirse, mientras que los objetivos son aspiraciones. Documentación – La documentación de las pruebas de rendimiento debe ser estratégico
conjunto que mide los requisitos y objetivos de rendimiento. La estrategia de la empresa puede requerir múltiples conjuntos de pruebas. No es necesario ejecutar todos los conjuntos a la vez. Por ejemplo, se ejecutarán conjuntos de pruebas de escalabilidad en preparación para momentos de gran actividad como la Navidad, mientras que se ejecutarán unas pruebas de humo como parte del proceso de compilación. Los patrones de uso de la aplicación se pueden identificar analizando los registros de uso de las aplicaciones web o de los patrones de uso que nos da el owner del producto o el departamento de marketing. Estos se tienen en cuenta para crear el conjunto de pruebas. El conjunto de pruebas debe someterse a cambios para satisfacer las necesidades cambiantes de la aplicación. Se agregan nuevas pruebas de rendimiento para abordar las nuevas características del producto; las pruebas de rendimiento antiguas están en desuso por características obsoletas (refactorizar los test); las pruebas de rendimiento existentes mejoraran en función del análisis de los informes de rendimiento, los comentarios del owner de la aplicación o los datos del departamento de marketing.
de rendimiento se analizan para detectar casos en los que no se cumplen los requisitos de rendimiento; estos se registran como defectos críticos. El desempeño también se compara con la línea de base para observar la tendencia. Cualquier deviación se informa al equipo para su posterior análisis y acción. Optimización rendimiento El equipo debe revisar y modificar la aplicación para abordar los defectos y preocupaciones planteadas por los informes de rendimiento. Estos cambios de ajuste pueden incluir modificaciones en la configuración, la red, la arquitectura, la topología, etc.
objetivos de desempeño Crear/Actualizar conjunto de pruebas de rendimiento Ejecutar los test de rendimiento 1ª ver se publica la línea base en 2ª o sucesivas ejecuciones resultado comparativo Nuevos test identificados Analizar Recopilar las métricas de rendimiento Optimizar
Esta explicación es para equipo Windows 10. Para seguir el workshop adecuadamente, seleccionar las versiones que se indican en cada paso. 1. Instalar JAVA SE Development Kit 9.0.4. 2. Establecer la variable de entorno JAVA_HOME a C:\Program Files\Java\jdk-16.0.1 3. Establecer la variable de entorno PATH a %JAVA_HOME%\bin 4. Establecer la variable de entorno CLASSPATH a %JAVA_HOME% \lib 5. En el CLI del sistema, probar: echo %JAVA_HOME%. Debe mostrar el valor del paso 1. 6. Verificar que Java se ejecuta correctamente. Entrar en el CLI del sistema y poner: java –versionY verificar que Java se ejecuta correctamente. Entrar en el CLI del sistema y poner: java –version 7. Instalar JMeter 5.4.1 (version en la que se basa este documento): http://jmeter.apache.org/download_jmeter.cgi 8. para ello baja los binarios en formato zip. Apache JMeter – Nuestro aliado
siguiente: /bin: contiene los scripts de inicio. /docs: documentación. /extras: ficheros de ant. /lib/: librerías. /lib/ext: los ficheros del core y protocolos. /lib/junit: librerías de JUnit usadas por JMeter. /printable_docs: documentación html. 9.Ejecutamos JMeter, tenemos 3 opciones: a)Modo GUI: dentro de /bin/jmeter.bat b)Modo servidor: dentro de /bin/jmeter-server.bat c)Modo CLI.
muy simple vamos a establecer un paso a paso con la opción más sencilla: HTTP(S) Test Script Recorder. Este es el guion de nuestra prueba: 1. Lanzar JMeter y preparar la grabación de nuestro script. 2. Configurar el navegador para utilizar el grabador de scripts de prueba de HTTP(S) JMeter. 3. Grabar el script (con dos opciones diferentes). 4. Agregar reports a nuestro script 5. Validar nuestro script con un solo usuario. 6. Configurar la prueba de carga (definir cantidad de usuarios, iteraciones, duración del warm-up y duración de la prueba de carga). 7. Ejecutar y analizar la prueba de carga. Con un ejemplo – Tras la teoría viene algo de práctica
test esta listo: 5.Para ahorrar tiempo en el futuro, puedes ir a la sección “HTTP Request Defaults” y rellenar el “Sever Name or IP” + “Port Number”, con los datos que suelas usar por defecto. 6.Tenemos varias opciones para la nomenclatura de las transacciones que grabemos:
defecto de la plantilla ya es capad de filtrar request que no nos interesen: 8.Con estas acciones ya estamos preparados para grabar nuestra sesión de navegación.
script: Y obtendremos los informes que hemos añadido anteriormente. En la sección de View Result Tree podréis ver casi lo mismo que Postman, pero con más información, es más completo, casi a la par que Fiddler.
Report: La información que vemos es muy poca, esto mismo lo podríamos haber realizado con Postman, pero a partir de aquí la información que podemos ir obteniendo en los informes ya comienza a superar a Postman u otra herramienta de test de APIs que incorpore algo de reporting.
script, lo lógico es usar pocas request y pocos usuarios hasta estar seguros, ya que si lanzamos en test contra Azure el coste podrá incrementarse y no es necesario en estos momentos: Y validamos: Validación – No debemos ejecutar un gran número de request si estamos validando
10 usuarios virtuales (VU) que llegan en 10 segundos (1 por segundo) y cada uno realiza 100 ejecuciones de la consulta. Y ejecutamos, de momento no hablaremos de la interpretación de los datos: Configuraciones – ¿Qué podemos cambiar rapidamente?
práctica ejecutar estas pruebas desde JMeter GUI, ya que esto no es óptimo para rendimientos de inyección. A la hora de realizar pruebas de carga, es recomendable monitorizar los inyectores (servidores donde se ejecutan JMeter, jerga de este software) al menos durante la primera prueba a plena carga para validar el correcto comportamiento de los inyectores. Esto asegura que, si tenemos malos tiempo de respuesta, la causa es la aplicación y no JMeter. ¡Cuidado! No es especifico de JMeter, se extrapola a cualquier herramienta que uses. Una solución fácil para monitorear JMeter es usar un complemento llamado Server Perfomance Monitoring: https://jmeter-plugins.org/wiki/perfmon Por tanto, una best practices es ejecutarlo en el CLI, que en jerga de JMeter es: Non-GUI mode. <JMETER_HOME>/bin/jmeter -n -t [jmx file] -l [results file] -e -o [Path\ to output folder] Analizar – Ejecutar y analizar las pruebas de carga
tenemos que hacer es guardar los cambios a nuestro fichero. Y ejecutamos con el CLI: jmeter -n -t C:\temp\JMeterResults\JMeterWebApi.jmx -l C:\temp\JMeterResults\JMeterWebApiResult.csv -e -o C:\temp\JMeterResults\Result El resultado que obtenemos este informe: Report HMTL del estándar de APDEX (https://en.wikipedia.org/wiki/Apdex).
importante nuestro fichero CSV con los resultados: Que puedes utilizar para cargarlo en cualquier herramienta de análisis, desde Grafana, PowerBI hasta un Excel y sacar tus propios gráficos.
vamos a centrarnos en Azure Load Testing, como praxis principal, si por alguna razón el cliente en el que trabajes no te permite usar Azure, puedes optar por esta opción, que detallo antes de la de Azure. 1. Crear un Backend Listener contra InfluxData. 2. Desplegar un servidor de Grafana y conectar este dashboard https://grafana.com/grafana/dashboards/3351
vamos a centrarnos en Azure Load Testing, como praxis principal, si por alguna razón el cliente en el que trabajes no te permite usar Azure, puedes optar por esta opción, que detallo antes de la de Azure. 1. Crear un Backend Listener contra InfluxData. 2. Desplegar un servidor de Grafana y conectar este dashboard https://grafana.com/grafana/dashboards/3351
trabajar es usando Azure Application Insight, os cuento esta otra jugada, ya que es posible que por temas de IPs, restricciones o que simplemente no han validado como herramienta Azure Load Testing en tu departamento de arquitectura, existe un workarround que a mí me ayuda mucho a la hora de mirar cómo van las cargas: 1. Crear el recurso de Azure: 2. Usar este plugin de JMeter: https://github.com/adrianmo/jmeter-backend-azure
y comenzamos a usar KQL en Insights: Donde nos muestra una lista de ejecuciones de los test que usaremos a continuación: requests | extend TestStartTime = tostring(customDimensions.TestStartTime) | distinct TestStartTime, name | extend formattedTestStartTime = format_datetime( unixtime_milliseconds_todatetime(tolong(TestStartTime)), 'yyyy/MM/dd HH:mm:ss' ) | sort by TestStartTime desc
= "<The value of the previously obtained "name">"; let TestStartTime = "<The value of the previously obtained "TestStartTime">"; let interval = "<interval (e.g. 100ms, 1s)>"; requests | where name == testName and customDimensions.TestStartTime == TestStartTime | extend Label = tostring(customDimensions.SampleLabel), SampleStartTime = unixtime_milliseconds_todatetime(tolong(customDimensions.SampleStartTime)) | summarize duration = avg(duration) by bin(SampleStartTime, totimespan(interval)), Label | render timechart
herramientas tienen sus peculiaridades y JMeter no es la excepción. Es importante comprender los conceptos para sacar todo el potencial a JMeter. Scope (alcance): En JMeter todos los elementos se organizan en un árbol, donde cada nodo tiene padres e hijos. Por tanto, el alcance se propaga del padre a los hijos. En la siguiente captura puedes ver que una Response Assertion (afirmación de respuesta), incluye a los elementos hijos. Sacar el máximo potencial – Peculiaridades de JMeter que debes conocer
ejecución de los elementos: La ejecución de los elementos en JMeter dependen de su tipo y del alcance: Los samples y controllers, no son elementos de ámbito (scope): se ejecutan donde se encuentran. El pre-processor, post-processor, timer, assertion y listener (pre y post procesado, temporizadores, afirmaciones y oyentes) son elementos de tipo scope: se ejecutan donde aplica su alcance y su orden de ejecución, depende tanto de su tipo como de la posición. Los elementos de configuración son de tipo scope, pero su ejecución depende de tu propio tipo. Podemos definir esta regla de orden de ejecución: Pre-Processor Timer Sampler Post-Processor Assertion Listener
en el editor GUI se puede mover, los arrastras y los dejas donde te interesa, pero recuerda que algunos por mucho que los muevas se ejecutan según su naturaleza, ver por ejemplo el timer: ¿Cómo funciona el scope del timer? Los temporizadores son importantes para simular el “think time” de nuestro script. El tiempo de reflexión es el tiempo que tarda un usuario entre dos iteraciones con la aplicación para hacer cosa tales como: Leer el contenido de la pantalla. Meter el nombre y contraseña del usuario. Imputar datos en un formulario. Para evitar comportamientos inesperados, es fundamental comprender como y cuando se ejecutan los temporizadores. Existen 2 reglas y se aplican independientemente de su ubicación:
un timer se ejecute como nos gustaría: Debemos añadir un elemento algo diferente al timer normal: El anterior razonamiento nos vale para los random timers. Timer1 Sampler1 Timer2 Sampler2
el scope con Assertion? Las afirmaciones se usan para validar una respuesta, por defecto JMeter considera los 4xx y 5xx como respuestas fallidas. Al igual que los temporizadores, también tienen reglas que se aplican independientemente de la ubicación de la afirmación, pongo algunos ejemplos: En este caso afirmación se ejecuta tras los dos sampler: En este otro, tras cada sampler:
con las afirmaciones que provocan un bajo rendimiento: XPath, XML, XML Schema o HTML. Limta el uso de afirmaciones, la que realmente tiene un beneficio real es la XPath. Y como recomendación usa las afirmaciones como elementos secundarios de los sampler (muestreadores, que explicaré más adelante). ¿En qué se diferencian las propiedades de las variables? Ambas permiten que JMeter sean dinámicos, por tanto, su propósito es similar: Las variables están estrechamente vinculadas a los hilos, lo que significa que tiene su propia copia y puede manipular su propia versión de la variable. Las propiedades se comparten entre todos los subprocesos. Por tanto, las variables son locales y las propiedades son globales. Esto nos da unas reglas:
propiedades deben usarse para datos relacionados con el environment (entorno). • Las variables para datos relacionados con el usuario y reglas de correlación. Por eso mismo, los extractores de Jmeter crean variables. Creamos propiedades de la siguiente forma: • jmeter.properties • user.properties • Usando el comando –J, –G, -p, -q (ver ayuda de JMeter). • Tambien se pueden usar ${__setProperty(propName, propValue. • Con scripting JSR223 usando: prop.put(“propName”, “propValue) o prop.setProperty(“propName”, “propValue) Creamos variables de la siguiente forma: • Usando un elemento de configuración • Usando parámetros, en un preprocesado. • Usando funciones JMEter (https://jmeter.apache.org/usermanual/functions.html) • Usando extractores de Jmeter (https://jmeter.apache.org/usermanual/component_reference. html#postprocessors) • Con vars.put(“varName”, “varValue”) o vars.putObject(“varName”, “varValue”).
Controllers? Cada subproceso tiene uno o varios controladores. Los controladores lógicos deciden el flujo de ejecución. Determinan el próximo sampler a ejecutar. JMeter viene con muchos controladores lógicos incorporados que brinda un flujo de control preciso. Por ejemplo: If, Switch, ForEach, While, For, etc. Y puedes programar los tuyos si lo deseas. Un sampler es un elemento hijo de un grupo de subprocesos o un controlador. Envia solicitudes a un servidor. Para cada protocolo, necesitamos un sampler (muestreador). JMeter tiene muchos out-the-box como, por ejemplo: request HTTP que es el más usado. Lo mismo ocurre, puedes desarrollar los tuyos. ¿Qué son los listener? Oyentes, los que escuchan las respuestas del servidor, ensamblan y agregan métricas de rendimiento. Se utilizan para mostrar gráficos. Al menos un listener debe existir en tu script para que podamos interpretar y comprender los resultados de la prueba de rendimiento. ¿Qué puedes contarme de los pre y post procesadores? Los preprocesadores cogen la solicitud y la modifican (sustituyen valores, mejoran, eliminan variables, etc.) antes de que el sampler envié la información al servidor. Los post-procesadores, procesan la respuesta del servidor y se usan para modificar la configuración o actualizar variables.
Nos sirve para configurar placeholders (marcadores) de las propiedades incluidas las definidas en propiedades y variables. Por ejemplo, en HTTP Cookie Manager es un elemento de configuración. Se puede usar con un nivel de anidamiento, cuidado. A continuación, y para el final dejo dos componentes muy importantes. El Test Plan Es el elemento raíz, el padre de todos. Este contenedor que contiene componentes tales como grupos de procesos, el controlado lógico (controller), el muestreador (sampler), el temporizador (timer), la aserción (assertion) y la configuración. Un plan de prueba consta de uno o más subprocesos.
importantes son: Añadir variables, via par/valor. Ejecutar grupos de subprocesos de forma consecutiva, es decir, de uno en uno. Si no lo marcas, se ejecutan en paralelo. Ejecución de subprocesos tearDown (demoler) tras el cierre de un subproceso principal. Se suele usar para tareas posteriores a la prueba con la finalidad de generar informes o para realizar limpieza. Tanto classpath como functional test, no las vamos a usar, es más functional test es incluso una opción poco recomendable debido a que guardar valores en los listener y esto genera inconsistencias, y classpath es para cargar ficheros JAR (nunca lo he usado) Diferencia de ejecución entre subgrupos secuencial (imagen izquierda) y en paralelo (imagen derecha):
El grupo de subprocesos es un punto de partida de ejecución de test. Todos los elementos pueden ser elementos secundarios de un plan de pruebas o un grupo de subprocesos, excepto controller y sampler, que solo pueden ser elementos secundarios de un grupo de subprocesos. Un subproceso simula la carga generada por los usuarios y representa un caso de uso. Un plan de pruebas puede tener varios grupos de subproceso, simulando así varios casos de uso. Aunque es poco común y no es deseable, se pueden intercambiar datos entre casos de uso, pero no lo recomiendo.
de pruebas puede tener varios grupos de subproceso, simulando así varios casos de uso. Aunque es poco común y no es deseable, se pueden intercambiar datos entre casos de uso, pero no lo recomiendo. Aquí puedes ver los tres tipos de subprocesos que puedes generar: A parte del normal, por defecto JMeter nos muestra setUp y tearDown. Y otros que puedes añadir como plugin, cada uno de ellos emula un escenario diferente: leer la documentación por si es necesario simular ese escenario en particular:
realidad es otra, casi seguro que has tenido que reutilizar trabajo y por tanto cambiar los test para no utilizar los plugins es un problema muy importante a la hora de adoptar Azure Load Testing. Si este es tu caso y no los está realizado desde 0, está de enhorabuena por qué sí que puedes añadir los plugins en Azure Load Testing: Añadir plugins en Azure Load Tesing
tipo setUp, se usa para realizar acciones necesarias antes de que comience la ejecución de un subproceso normal. Puede ser útil para iniciar una sesión y coger los headers, ejecutar script de inicialización de bases de datos, etc. • El tipo tearDown, se usan para acciones necesarias tras la ejecución normal. Puede ser útil para borrar bases de datos, deshacer cambios, etc. Los grupos de subprocesos tiene tres elementos que vamos a explicar, es muy importante comprenderlos bien:
del thread, esto es muy importante, como ya habéis visto en el apartado anterior: • Number of Thread (users): número de usuarios que queremos emular. • Ramp-up Period (senconds): tiempo en el que volverá a activarse el thread, es decir, termino un thread y espero X segundos (lo que hemos puesto en la casilla) para volver a ejecutarse. • Loop count: cuantas veces vamos a ejecutar el thread, si pones un valor en la casilla serán las veces que inicias, si no pones nada se activará infinito. • Same user on each iteraction, se usa por ejemplo si quieres que las cookies y las caches permanezcan entre iteraciones, por ejemplo. Cuidado si tienes un proceso de borrado de cache, la que manda es esta opción y no hace caso al borrado de la cache. • Specific thread life time, nos vale para ejecutar el test durante un tiempo dado, si lo pones con infinito, se ejecutará las veces que pueda durante ese periodo de tiempo. Nos puede valer para emular la carga del sistema en un momento dado, por ejemplo, si tenemos una tienda y la oferta es como un Happy Hour, podemos simular el comportamiento. Como puedes observar la jerga de JMeter es peculiar y a los desarrolladores del ecosistema .NET nos puede sonar muy extraña.
a contar en parte no tiene mucho interés en Azure Load Testing, pero sí que debes entender bien la teoría para poder hacer buenos test. Aunque ya hemos visto la palabra injector (inyector), merece un pequeño paréntesis para explicar esto. Incide directamente en la precisión de los resultados, si no, la prueba se ver degradada y no tendría sentido la prueba de carga. Nunca alojes el inyector (JMeter) en el mismo servidor de lo que queremos probar. Debes tener sistemas dedicados, lo vemos con estos gráficos: Preparando el entorno de Test – Entiende el concepto Jmeter Localhost Application under test Server Latency: 0,152 ms Jmeter Localhost Load Balancer Inyector Latency: 0,252 ms Server Under Test Application under test Latency: 22 ms
de lanzar la prueba grande, debemos ejecutarlo con una pequeña porción de usuarios, por ejemplo, el 10% de los usuarios objetivo. Nos permitirá verificar: 1. Si el script va bien con múltiples VU. 2. La configuración de los think times y el rendimiento del script. 3. Que las assertions funcionan. 4. Nos dará el baseline de referencia, nos ahora tiempo. Tendremos el baseline de 10% y el del 100% para la prueba final. Desde el punto de vista organizativo nos permite verificar que cada rol implicado en las pruebas está disponible, ver si el sistema de monitorización está funcionando con todos los componentes y revisar el informe final, que esté correcto y no tenga algún tipo de error. En resumen, estas pautas nos sirven para ahorra tiempo y no darnos cuenta cuando llevan 3 horas funcionando nuestro test. Estas cosas pueden llevar 15 minutos.
que los inyectores no estén sobrecargados para que la interpretación de los datos no esté distorsionada. Prueba los inyectores con la herramienta de monitoreo correspondiente, si es una VM de Azure usa las herramientas para ver la memoria, ancho de banda, si existen proxys saturados o algún firewall funcionando mal, etc. Si todo es correcto, nos permitirá fiarnos de los resultados. IP Spoofing Suplantaciones de IP. Nos permitirá en el inyector simular solicitudes desde distintas IP. Esto se usa para probar los load balancer, por ejemplo, o eludir un bloqueo de solicitudes masivas de nuestro sistema y lo interprete como un ataque de DDoS. Jmeter IP: 192.168.1.10 IP: 192.168.1.11 Load Balancer IP stickiness Inyector Request 2: IP 192.168.1.11 Request 1: IP 192.168.1.10
Por defecto JMeter usa 1GB. Pero en ciertos casos deberás cambiar este valor. Dirígete a la documentación para cambiar estos parámetros: set HEAP="-Xms2g -Xmx2g -XX:MaxMetaspaceSize=256m" Evita pruebas de carga tras un proxy Parece obvio, pero en este caso estarías probando el proxy y no necesariamente la aplicación de destino. De hecho, un proxy puede ser un cuello de botella durante una prueba. No olvides que podría estar siendo usado por otros empleados de la empresa, otros sistemas, introduciendo variables de entorno incontrolables para la prueba. Es decir, que mete tanta variabilidad que no serían condiciones reproducibles y conocidas. Como jugada interesante y que puede ayudar a nivel comercial es que podemos incluso probar el Proxy dar los tiempos que genera nuestra REST API. Es decir, no probamos el SLA del servicio si no, que métricas nos ofrece nuestra aplicación entre un usuario en Kenia y nuestro endpoint en España o nuestro usuario en Buenos Aires y la base de datos de España. Con esta métrica medimos nuestra infraestructura. Y esto sería una buena práctica para medir proxies.
Preparación del sistema a probar Visto que el inyector merece una preparación. No menos importante es el sistema sometido a pruebas. Algunas pinceladas ya las hemos visto en la otra parte teórica. Para evitar perder tiempo buscando errores que no están relacionados con el rendimiento, es importante que la aplicación este estable y probada a fondo. Si las pruebas de carga se escriben justo antes de las de implementación, quedará poro tiempo para las pruebas. Eso significa que si la aplicación no ha sido probada funcional y técnicamente (pruebas unitarias y de integración, por ejemplo), cada error detectado durante las pruebas de carga pondrá en peligro la fecha de inicio de puesta en producción. Las pruebas de carga (podremos usarlas en integración continua de forma automatizada) nunca han de usarse para reemplazar las pruebas de regresión. Un entorno coherente e ideal, sería aquel que equivale al entorno de producción. Es decir: mismo hardware, software, configuración, conjunto de datos, mapeo de aplicaciones, etc. Si esto no es posible, céntrate en reducir la cantidad de servidores o potencia de los mismos, pero mantén la misma arquitectura de la aplicación: si tenemos un clúster de 4 nodos al menos mantén 2 nodos o baja la potencia a los 5 nodos.
Los dataset, son muy importantes. Tener un volumen de datos y un conjunto de buena calidad es mandatorio. Si los datos no existen, debes crearlos (con script, por ejemplo). Cosa a tener en cuenta con los datos: Cuando la versión anterior no tiene los mismos datos que la futura, debemos verificar que esta nueva version tendrá el mismo volumen de datos que la primera. Cuidado con que no se agoten los datos, si emulamos 1000 compras que los productos no se agoten. Esto da muchos falsos positivos y puede que te cueste mucho localizar el problema o no lo detectes y estas falseando el resultado final. Cuidado con las llamadas a servicios de terceros, principalmente por la factura final y secundariamente por que pueden bloquearte. Pide que te den un entorno de pruebas dimensionado para los test o bien usa mock si es posible, desde mi punto de vista es la mejor opción. Deshabilita los sistemas de protección, por temas de ataque de DDoS, por que podamos hacer creer al sistema que es un Bot, o que nos ponga un CAPTCHA o mismamente la protección del Load Balancer.
Usa entornos aislados. La principal ventaja es que eliminamos ruido a la hora de problema inesperados. Por ejemplo, notamos que durante unos minutos nuestras pruebas se han deteriorado, podría pensar en estas hipótesis: • Se ha lanzado la copia de seguridad. • Un grupo de usuarios que entra a trabajar, un cambio de turno. Sin embargo, si en el entorno aislado eso no existe, esa degradación no será por un agente externo no controlado. Licencias del software, os parecerá una tontería, pero me ha sucedido en la vida real, la licencia del entorno de producción es distinta a la del test, con Azure Function la de test llegó al máximo de uso y dejó de funcionar. Monitorizar, si los resultados de las pruebas no son los esperados, tendremos que investigar. Por tanto, cuanto más preciso y relevante sea la monitorización, más fácil será el análisis. Asegúrate de configurar la monitorización desde el principio, para no ir a ciegas, ya no solo para las pruebas de carga; es para todo.
adelantado algo antes, pero aquí entramos en más detalle. Visualizar y analizar los resultados de una prueba de carga es el objetivo final. Nos permite: • Validad nuestro script, que sea realista, que el número de transacciones coinciden, etc. • Depurar el script. • Ver cómo se comporta la plataforma con la carga de datos. • Ver cómo evoluciona en el tiempo las respuestas. • Ver los errores que ocurren. La visualización de los resultados de JMeter se basan en los listener. JMeter graba los resultados en diferentes formatos: • CSV, determinado y que ya hemos visto con el comando del CLI. • En XML. • Con InfluxDB, por defecto, importados a Graphana o en Elasticsearch, por ejemplo. • Con un pluging y enviándolo a Azure Insight. • Y por supuesto Azure Load Testing. Analizando los test – Los datos que arrojan los test y como interpretarlos
lo que hacemos es visualizar los datos que se obtiene de los listeners (Jmeter tiene una gran cantidad de listener o incluso plugins). Pero lo que nos interesa es usar las cosas estándar: View Result Tree. Este componente nos ofrece la vista detalla de la muestra de nuestra prueba, el controller o la respuesta de la asertions. Indica los tiempos de respuesta e información variada (tamaño en bytes, latencia, estado, etc.) los headers de cualquier dato transmitido incluso sus parámetros. Es un receptor muy útil para el desarrollo de un escenario de test por la información que nos muestra. Existen tres carpetas: • Sampler Result: resultado del muestreo con los tiempos de respuesta y los indicadores de rendimiento de la consulta. Además de información adicional para la solicitud enviada, como el tipo de codificación de datos y el contenido usado. • Request Tab: muestra la información de datos transmitiros en la solicitud al servidor. Podremos ver el header y el body de la request. • Response Data Tab: al igual que antes tanto body como header, que nos ayuda a estudiar si nuestra solicitud trabajó adecuadamente. Primero – Debes saber usar la herramienta JMeter para luego saltar a Azure Load Testing
componente que podemos utilizar es: Summary Report. Es la información estadística de los tiempos de respuesta y los resultados según la etiqueta de nuestro controlador de transacciones. Aggregate Report El mismo tipo de informa que el anterior, pero usando percentiles. Que puedes modificar usando las propiedades. Backend Listener Que usamos para exportar esta información a terceros. Ya lo usamos antes para enviar la información a Azure Insight. Tal y como vimos en con el CLI podemos generar un Report Dashboard, que en el GUI está en: Ver más información en https://jmeter.apache.org/usermanual/generating-dashboard.html y recuerda APEX que mencioné con anterioridad.
que os he contado antes, si no sabes leer los resultados, nuestro análisis será una falacia. Para evitar esto, os pongo unos consejos. Mejor percentil que promedio. El promedio se usa mucho por ser fácil de leer y calcular. Pero los valores medios y medianos no reflejan correctamente la experiencia del usuario: • Tienden a ocultar valores atípicos. • Distorsionan la realidad. • Y ocultan la distribución de datos. Consejos – Para interpretar los resultados
ejemplo es el chiste del pollo y los dos comensales: tengo un pollo me lo como yo y tu nada, estadísticamente ambos hemos comido medio pollo. Para evitar esto se usa el percentil. El percentil XX es el valor por debajo del cual se puede encontrar el XX% de los valores. Pero con cuidado: • El hecho de que nuestro percentil 99 sea bueno, no significa que el tiempo de respuesta sea bueno en la vida real. Ver: http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-most-page-loads.html • Y cuidado como calculas los percentiles, distintas herramientas, distinta forma de calcularlo. Mantén una homogeneidad. Cuidado con la reducción y la retención del submuestreo. El submuestreo es el proceso de reducir número de muestras en los datos. Algunas bases de datos de series temporales solo almacenan información durante X tiempo y el resto con menor precisión. Esto significa que, si necesitamos hacer un análisis a posteriori, perdemos precisión (ocurre igual para percentiles). No debemos esperar a analizar los datos.
que con los mismos resultados se ven muy diferentes los gráficos (el tiempo promedio máximo no es el mismo y así sucesivamente). Una base de datos de series temporales como InfluxDB o Dynatrace o Insight tienen: Policitas de retención de datos: se eliminan tras cierto tiempo. Políticas de agregación de datos: para reducir el volumen de los mismos. Asegúrate que puedes configurar las políticas para analizar los datos y nunca juegues con ella una vez configurada, desvirtúas los históricos de las series temporales. Mucho cuidado con la definición de las métricas. Es fundamental comprender la métrica que estas estudiando. Si no la entiendes, tu interpretación será falsa. Por ejemplo, el tiempo de respuesta promedio en JMeter es: tiempo de red que toma la solicitud para pasar de JMeter a la aplicación bajo prueba + tiempo para que la aplicación bajo prueba procese la respuesta (backend) + tiempo de red que tarda la respuesta en pasar de la aplicación bajo prueba a JMeter Jmeter Localhost Application under test Request Response Average Rsponse Time Network Backend
en un navegador: Tiempo de red que toma la solicitud para pasar del navegador a la aplicación bajo prueba + tiempo para que la aplicación bajo prueba procese la respuesta + tiempo de red que tarda la respuesta en pasar de la aplicación bajo prueba al navegador + tiempo para que el navegador muestre la respuesta Browser Application under test Request Response Average Rsponse Time Network Backend Frontend
el tiempo inicial de respuesta al comenzar la carga. Siempre es un proceso pesado en el lado de la plataforma por que probablemente: • Debe crear o instanciar recursos, conexiones, etc. • Llenar caches. • Iniciar mecanismos de escalados. • Distribuir cargas. • El pool aumenta. • Debe calentar los servicios.
pruebas de carga cortas. Basar el promedio o percentiles e intentar extrapolar no tiene sentido. Mira la distribución temporal. Con cualquier métrica observa la distribución. Nos permitirá validar el funcionamiento. La grafica de la izquierda nos dice que la respuesta tiene una distribución semi-normal y extrapolable. Mientras que la derecha no podemos asociar a una gráfica conocida, parecen dos distribuciones semi-normales y lo que interpretamos es que: existen request muy rápidas y otras muy lentas.
prueba carga y generados lo datos, toca presentarlos para: • Mostar los tiempos de respuesta y estabilidad antes de entrar en producción. • Permitir que Operaciones solucione problemas de configuración. • Permitir a Desarrollo que soluciones problemas. • Solicitar presupuesto para más recursos on-premise o en la nube. • Informar a los C-Level y demás roles implicados. Presentar esta información no es fácil y aun menos si debes dirigirla a un rol en concreto. No promedies los percentiles. Calcular el promedio de un percentil es matemáticamente incorrecto. Cuidado con la resolución y lugar/formato de presentación de los datos. Las Métricas no se verían bien. Por tanto, define el número de métricas a mostrar en un gráfico de líneas de series temporales. Conejos – Ahora te toca presentar los resultados y explicar lo que ves
mostrar una comparación de usuarios activos (VU) frente a tiempo de respuesta, la gráfica anterior es un galimatías, concretas medidas y presenta varios gráficos: Define granularidad de las medidas. Es decir, no hace falta presentar segundos, puede mostrarlo en cuartos de minuto, medios minutos o minutos, depende de tu test. Aunque parece obvio: define etiquetas, leyendas y unidades en el gráfico. Fuerza el eje 0, si a partir de cierto valor los datos arrojan información para interpretar, limpia aquellos datos que no aportan nada. Nunca uses gráficos de tarta usa gráficos de barras o líneas. Estamos en un contexto en el que no tienen sentidos, estamos presentando series.
errores un los grafico relevantes con tooltips. Aunque ya viene en el Report Dashboard por defecto, si tienes que construirlo en PowerBI, nos permite ver: • Los tipos de errores. • Cuando ocurren los errores. No dejes de incluir para mí el más importante: el grafico de series temporales, que nos permite ver la evolución comparando con anteriores test. Comparación del baseline, en Azure DevOps no existe la opción que tenemos en Jenkins via plugin de realizar comparaciones entre el primero informe baseline (aquel resultado que decimos que es aceptable). Esto tendrás que hacerlo en PoweBI o Azure Load Testing o Excel mismamente:
comunes: • Testing de un sitio web (front). • Testing de un servicio web (con autenticación el back). • Testing de un servidor de base de datos, aquí no se incluye el test desde que se llama a un Azure Service Bus y es recuperado el dato, para mi el test de una arquitectura EDA la podríamos incluir en el apartado anterior. JMeter nos permite incluso hacer testing de un middleware orientado a mensajería (MOM), pero esto ya se sale del ámbito de la práctica o no terminaríamos nunca. Estos casos de uso y sus correspondientes ejemplos nos mostrarán el potencial de JMeter en las acciones más comunes que existen en el desarrollo diario. Siendo uno de estos casos será el que llevemos al paradigma de DevOps de la siguiente sección. Como punto final en esta sección vamos a ver una serie de recetas: buenas prácticas y problemas comunes. 3 Escenarios – Los principales en muchas apliaciones
como comenté en la teoría, frontales web, pero esto tenía sentido en el año en que se creó esta aplicación 2001 hasta 2015 si me apuráis. Entre 2009 y 2015 comienzan a aparecer aplicaciones SPA este tipo de aplicaciones y el conceto cambia, desde mi punto de vista solo tiene sentido probar aplicaciones que sirven páginas de servidor o componentes concretos como paginación de tipo oData. Por tanto, no vamos a ver estos escenarios, ya que existen herramientas para ver la parte de la carga en el frontal, además tal y como os conté en la teoría, es cuestión de percepción del usuario y los entornos finales que dispone la organización: no es lo mismo lo que tardará el PC de un Dev con 16 GB y un procesador de última generación que el de un administrativo que lo más que usa es Excel con 8GB y un procesador obsoleto. La organización debe ser coherente y proporcionar una experiencia de usuario fluida basada en la percepción. Esas herramientas son: • Perfomance y network de Chrome. • Google Lighthouse, con la métrica perfomance: https://developers.google.com/web/tools/lighthouse • Playwright. Ejemplo usando Artillery y Playwright. Web – Aquí la percepción también cuenta
de carga es usar un paginado, no podemos tener una request que nos esté cargando un objeto tan grande en memoria y esté tardando tanto tiempo en procesarlo. En JMeter ver la llamada de un GET All de 100.000 registros es aceptable 36 ms, pero pintarlos en pantalla nos lleva 55 s en montar y renderizar el componente con un consumo de memoria mínima de 263 MB es inaceptable y como desarrollador debemos atacar este problema, otra cosa es en los navegadores de los usuarios de la organización: usar la precepción.
de un front en React (usar yarn) y un back en .NET. En el front debemos cambiar el fichero AppSettings.ts y crear una cuenta de auth0 (que implementa OpenID) para poder configurar la autenticación y autorización de la aplicación. Para ello primero creamos la API Audience:
probar que os funciona con vuestra cuenta de GMail. Cada forma de autenticación y autorización que tengas en tu aplicación implica conocer muy bien su funcionamiento para poder extraer tokens y emular, por ejemplo, la forma de conectar. En nuestro caso es OICD para una SPA: Y no entramos en más detalles, ya que esto es suficiente para el ejemplo.
el código están ya protegidos. Y para poder probarlos es más sencillo apoyarse en Postman que empezar a bombardear con JMeter. Tal y como podéis observar si llamamos a POST https://localhost:44359/api/questions tendremos el esperado 401.
con 1 usuario, es decir, siguiendo las indicaciones que os conté en la parte teoría y no usando 100 VU, por ejemplo: 1. Un Listener de tipo View Report Tree 2. Un Listener de tipo Aggregate Graph.
y vamos a añadir que deseamos probar: Y ejecutamos. Como resultado de Aggregate Graph tenemos: Y la interpretación para el percentil 95 (recordar la teoría) indica el valor por debajo del cual cae un determinado número de observaciones. En este caso el %95 tiene una respuesta menor a 143969 ms, un valor excesivo debido a que el servidor era mi propio PC.
de los 1000 primeros registros y actualizarlos (para ello poner 1 usuario y 1 repetición, como os he explicado). Sacaremos el Id correspondiente del GET y lo pasaremos al PUT para que lo modifique. Deshabilita la request anterior y comenzamos con nuestro paso de variables:
10 = 100 request y agrupadas en nuestro informe: Con un %95 de 22 ms. Ahora vamos a pasar el contenido del Get al Put para realizar actualizaciones, una tras otra, recordar las reglas de ejecución de los Listener
breve API que interactúa con bucles y con variables, ya podrás construir casi la mayoría de tests que se te ocurran, y si no, busca en los listener, controllers, sampler, etc. Para hacer tu prueba. Dos casos muy comunes serian: Los Ids de los rows no fueses autonuméricos, si no GUID aleatorios, primero tendrías que ejecutar un GET de todos y guardarte los Ids en un array para luego ir haciendo las acciones de PUT. Otra opción es leer un fichero de datos. Para ello vamos a ver el siguiente ejemplo: JMeterQandA_04.jmx Lo primero es crear un CSV y poner una lista de Ids. En segundo lugar, añadir un Config Element de tipo CSV Data Set Config:
CSV: Obteniendo: Hemos pasado por todos los rows del csv, para ver los comportamientos es necesario leer la documentación, pero si sabes programar sabrás entrar encontrar la doc necesaria para poder hacer tu test.
que si no puedes hacer algo no te quedará más remedio que entrar en Beanshell y programar en JAVA. Beanshell aparece en distintos puntos como sampler, como preprocesador, postprocesador, assertion o function. Por ejemplo, en tu Plan Test tienes un HTTP Coockie Manager habilitado, puedes cambiar las cookies con el siguiente script: import org.apache.jmeter.protocol.http.control.CookieManager; CookieManager manager = ctx.getCurrentSampler().getProperty("HTTPSampler.cookie_manager").getObjectValue(); props.put("cookiecount",String.valueOf(manager.getCookieCount())); for (int i=0;i<manager.getCookieCount();i++){ // code to convert Cookie information to JMeter Properties props.put("cookie_name_" + i, manager.get(i).getName()); . . . } Evidentemente falta código. Y lo más importante solo puedes hacer un debug via jmeter.log.
opciones que suelen ser parametrizables en una prueba de carga y que podrías configurar tanto en tu archivo JMeter como en Azure Load Testing: • Número de usuarios virtuales (VUs): Define cuántos usuarios virtuales simultáneos ejecutarán la prueba. • Duración de la prueba: Especifica cuánto tiempo durará la prueba de carga. • Ramp-up time: El tiempo que se tarda en llegar al número total de usuarios virtuales. • Período de mantenimiento de carga: Cuánto tiempo se mantiene el número máximo de usuarios antes de que comience el ramp-down. • URL base: La URL del sitio web o servicio que estás probando. • Parámetros de solicitud: Parámetros que se enviarán con las solicitudes HTTP, como query strings, headers, body data, etc. • Variables de entorno: Variables definidas por el usuario que pueden usarse para personalizar las pruebas, como credenciales de usuario, tokens de API, etc. • Contadores de rendimiento: Especificar qué métricas de rendimiento recoger durante la prueba. • Ubicación geográfica de los usuarios virtuales: Dónde se ubicarán los usuarios virtuales que generan la carga. • Configuraciones de red: Configuraciones para simular condiciones de red, como latencia o pérdida de paquetes. • Pausas entre solicitudes: Tiempo de espera entre solicitudes consecutivas para cada usuario virtual. • Condiciones de error: Definir qué condiciones se consideran errores durante la prueba. • Límites de error: Establecer límites en el número o porcentaje de errores permitidos antes de que se detenga la prueba. • Scripts de pre y post-prueba: Scripts que se ejecutan antes de iniciar la prueba y después de finalizarla. • Integraciones y notificaciones: Configurar integraciones con otros servicios o sistemas de notificación para alertar sobre el progreso o resultados de las pruebas. En tu archivo JMeter deben estar definidas las variables o propiedades que puedan ser sobreescritas. Por ejemplo, si en tu archivo JMeter tienes una variable para el número de usuarios virtuales llamada NUM_USERS, deberías poder configurar esa variable en Azure Load Testing cuando subas tu archivo .jmx. Azure Load Testing – ¿Cómo me llevo el anterior ejemplo local al cloud?
como seguir estos pasos, además incluyo le uso de variables. No tiene sentido poner en el fichero el número de usuarios a mano ya que en los distintos entornos que lancemos desde Azure DevOps (por ejemplo) desharemos hacer distintos test. Paso 1: El fichero JMeter • Usar Variables: Para crear variables en tu Test Plan, puedes hacer clic derecho sobre el elemento donde quieras usar la variable (por ejemplo, en "HTTP Request") y seleccionar "Add" > "Config Element" > "User Defined Variables". Aquí puedes definir variables y sus valores predeterminados. • Parametrizar Samplers: En los elementos como "HTTP Request", puedes usar estas variables introduciendo la sintaxis ${nombre_variable} en los campos que quieras que sean dinámicos. • Guardar el Test Plan: Una vez que hayas configurado tu Test Plan, ve a "File" > "Save As" para guardar tu archivo con la extensión .jmx. Paso 2: Subir y configurar el fichero JMeter en Azure Load Testing • Acceder a Azure Load Testing: Inicia sesión en el portal de Azure y busca "Azure Load Testing" para crear o acceder a un recurso de prueba de carga. • Crear una nueva prueba de carga: Dentro de tu recurso de Azure Load Testing, selecciona "New test" o "Create test" para crear una nueva prueba de carga. • Subir el fichero JMeter: En la sección de configuración de la prueba, busca la opción para subir tu fichero JMeter (.jmx) que has creado en el paso 1. • Configurar variables: Después de subir el archivo, busca una sección donde puedas definir o sobrescribir las variables que has definido en JMeter. Usualmente, podrás encontrar una sección llamada "Parameters" o "Configuration" donde puedes establecer los valores de las variables que serán usadas durante la prueba de carga. • Ejecutar la prueba de carga: Una vez configuradas las variables, puedes proceder a iniciar la prueba de carga y monitorizar los resultados. Paso 3: Cambiar las variables en Azure Load Testing • Editar la prueba de carga: Ve a la configuración de la prueba de carga existente en Azure Load Testing. • Modificar variables: Accede a la sección de parámetros o configuración y cambia los valores de las variables según necesites. • Guardar y ejecutar nuevamente: Guarda los cambios y ejecuta la prueba de carga nuevamente para ver el impacto de las nuevas variables. Azure Load Testing – ¿Qué más puedo parametrizar?
ir más rápido, con testear una sola consulta podrás ver el potencial y el informe que nos da (saber interpretarlo). Lo primero es probar contra un Storage Table y luego contra un SQL Server. En menos de 5 minutos tenemos una primera versión, sin parametrizar ni usando buenas prácticas. Pero ya hemos testeado nuestro Azure Storage Table, lo mismo pasaría para Cosmos DB, etc. Existe muchas formas – Pero veamos como hacerlo con JMeter
tiene sus propias herramientas, pero lo tendríamos por separado y deberíamos generar un documento de Test juntando diversas piezas. Como SQL Server es parte del Backend, desde mi punto de vista, es buena práctica meter los test de perfomance de nuestro Servidor. Como mínimo nos vale de baseline para decir que las pruebas de los servicios Rest API, que hacen uso de las mismas, no están afectadas por parte del servidor de base de datos. Nuestro sistema queda perfectamente controlado. Lo primero es instalar los drivers: https://docs.microsoft.com/es-es/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-ver15
las anteriores explicaciones he ido desgranando alguna buena práctica, aquí voy a mostraros algunas más que nos ayudarán con el día a día: • Usar HTTP Request Defaults, para que se aplique en todo el Test Plan. Evitarás hacerlo en cada punto. • Usa Follow Redirect o redireccionamientos. Los famoso 3XX. • Usa Cookie Manager bien definidos separa las globales y son del scope concreto. • Usar HTTP Cache Manager, como JMeter no es un browser real, esto no evita que podamos renderizar contenido o ejecutar JS. Tiene mucho sentido en pruebas de frontal. • Si necesitas pasar variables entre grupos es mejor usar un Beanshell y crea la variable dinámicamente (como se explicó en los pre y los pro), por ejemplo, si pasas una URL. • Marca la opción de ejecutar Thread Group en paralelo, es la vida real, los usuarios no entra como en una cola. • Monitoriza los errores, si haces click en el icono superior derecho te saldrá el log de errores. • Intenta usar los Templates, ya nos ofrece un plan con las opciones más habituales y son un buen punto de partida. • Desactivar o Eliminar Listeners Durante la Prueba de Carga: Los listeners pueden consumir mucha memoria y CPU. Úsalos solo durante la fase de desarrollo y desactívalos o elimínalos en las pruebas de carga reales. • Usar Timers de Manera Efectiva: Los timers ayudan a simular el tiempo de pensar del usuario real. Configura los timers adecuadamente para espaciar las solicitudes de los usuarios virtuales. • Revisar la Configuración de JVM: Asegúrate de que la configuración de la JVM esté optimizada para las pruebas de carga, especialmente si planeas ejecutar pruebas con una gran cantidad de usuarios virtuales. • Utilizar Assertions con Prudencia: No abuses de los assertions, ya que pueden tener un impacto significativo en el rendimiento. Utilízalos solo para validar aspectos críticos de la respuesta. • Uso de CSV Data Set Config: Si necesitas inyectar datos desde un archivo externo (por ejemplo, para la autenticación de usuarios), usa el componente CSV Data Set Config de JMeter. • Evitar el uso Excesivo de Samplers de JavaScript: Si bien los samplers de JavaScript pueden ser útiles, también pueden ser muy costosos en términos de rendimiento. Úsalos solo cuando sean estrictamente necesarios. • Uso de Extractores de Datos (Post-Processors): Usa extractores de datos como el extractor de expresiones regulares o el extractor JSON para capturar datos dinámicos de las respuestas y reutilizarlos en solicitudes posteriores. • Modularizar tu Test Plan: Usa módulos y pruebas incluidas para reutilizar lógica común y hacer que tu Test Plan sea más mantenible. Un poco de ayuda – Siempre es bueno tener presente este tema
Testing: • Configuración de la Red Virtual: Si estás ejecutando pruebas de carga en un entorno de Azure, asegúrate de configurar la red virtual adecuadamente para permitir la comunicación entre Azure Load Testing y tu aplicación. • Utilizar Azure Monitor: Integra Azure Monitor para obtener métricas detalladas y realizar un seguimiento de la salud de tu aplicación durante la prueba de carga. • Almacenamiento de Artefactos de Prueba: Utiliza Azure Blob Storage para almacenar los resultados de tus pruebas de carga y tener un histórico de rendimiento. • Gestión de Identidades y Accesos: Asegúrate de gestionar correctamente las identidades y los accesos de los usuarios que ejecutan las pruebas de carga en Azure para mantener la seguridad. • Automatización con Azure DevOps: Integra tus pruebas de carga con Azure DevOps para automatizar su ejecución como parte de tu proceso de CI/CD. • Escalabilidad de la Prueba de Carga: Aprovecha la escalabilidad que ofrece Azure para simular una gran cantidad de usuarios virtuales sin la necesidad de infraestructura propia. • Revisión del Costo: Monitorea y optimiza los costos asociados con la ejecución de pruebas de carga en Azure, para asegurarte de que estás utilizando los recursos de manera eficiente. • Uso de Tags y Filtrado: Organiza tus pruebas de carga utilizando tags y filtros para facilitar la identificación y análisis de diferentes ejecuciones o configuraciones de pruebas. • Análisis de Tendencias y Comparación de Resultados: Utiliza las herramientas de análisis de Azure para comparar resultados de pruebas de carga a lo largo del tiempo y detectar tendencias o degradaciones en el rendimiento. • Configuración de Alertas: Configura alertas en Azure para notificarte de inmediato si se alcanzan ciertos umbrales de rendimiento o si ocurren errores durante las pruebas de carga. • Realizar Pruebas de Carga Regularmente: Integra las pruebas de carga en tu ciclo de vida de desarrollo de software para identificar problemas de rendimiento de manera temprana y frecuente. • Documentación y Compartir Resultados: Documenta tus pruebas de carga y comparte los resultados con tu equipo para fomentar la transparencia y mejorar la colaboración. • Revisar y Actualizar Test Plans Regularmente: Al igual que el software evoluciona, tus planes de prueba de carga también deben hacerlo. Revisa y actualiza tus test plans para que reflejen cambios en la aplicación. • Pruebas de Estrés y de Sobrecarga: Además de las pruebas de carga estándar, considera realizar pruebas de estrés para entender cómo se comporta tu sistema bajo condiciones extremas y hasta qué punto puede manejar la sobrecarga antes de fallar. • Seguimiento de Versiones: Asegúrate de tener un control de versiones de tus archivos JMeter y de las configuraciones de prueba en Azure para poder rastrear cambios y revertir a configuraciones anteriores si es necesario. • Uso de Grupos de Recursos: Organiza tus recursos de Azure Load Testing en grupos de recursos para gestionar mejor los permisos, políticas y facturación. • Evaluación de la Seguridad: Asegúrate de que las pruebas de carga no comprometan la seguridad de tu aplicación o infraestructura. Realiza revisiones de seguridad y sigue las políticas de cumplimiento. • Optimización de Recursos de Azure: Evalúa y ajusta los recursos de Azure utilizados durante las pruebas de carga para encontrar un equilibrio entre el costo y el rendimiento.
comunes: • Testing de un sitio web (front). • Testing de un servicio web (con autenticación el back). • Testing de un servidor de base de datos, aquí no se incluye el test desde que se llama a un Azure Service Bus y es recuperado el dato, para mi el test de una arquitectura EDA la podríamos incluir en el apartado anterior. JMeter nos permite incluso hacer testing de un middleware orientado a mensajería (MOM), pero esto ya se sale del ámbito de la práctica o no terminaríamos nunca. Estos casos de uso y sus correspondientes ejemplos nos mostrarán el potencial de JMeter en las acciones más comunes que existen en el desarrollo diario. Siendo uno de estos casos será el que llevemos al paradigma de DevOps de la siguiente sección. Como punto final en esta sección vamos a ver una serie de recetas: buenas prácticas y problemas comunes. 3 Escenarios – Los principales en muchas apliaciones
+ Test Build Unit Test Quality Checks Package Deploy Integration Test Functional Test Load Test Binary Repository Get Source Push Get Binaries P i p e l i n e s Reporting Promote Production
prodreis sacar todo el partido tanto a Azure Load Testing, como Playwrite y Azure Chaos Studio, no creo que pueda explicaros mejor y daros un ejemplo mejor que este. Aun así, voy a poner paso a paso que se debe hacer para poder probar nuestro backend: Paso 1: Configurar Azure Load Testing • Crea un recurso de Azure Load Testing en tu suscripción de Azure si aún no lo has hecho. • Configura tu prueba de carga en Azure Load Testing, subiendo tu archivo JMeter (.jmx) y estableciendo las variables y parámetros necesarios. Paso 2: Configurar Azure DevOps • Accede a tu proyecto en Azure DevOps. • Ve al apartado de "Pipelines" y selecciona "New pipeline" o edita una pipeline existente. Paso 3: Crear o Editar una Pipeline de Azure DevOps • Selecciona el repositorio de código fuente donde se encuentra tu código y configuración de pruebas. • Elige el modelo de pipeline que prefieras (YAML o Clásico). Azure DevOps – Esto también se puede hacer con GitHub
Paso de Azure Load Testing en la Pipeline Si estás utilizando la interfaz clásica: • Añade una nueva tarea a tu pipeline buscando "Azure Load Testing" en el mercado de tareas de Azure DevOps. • Configura la tarea con los detalles de tu prueba de carga, incluyendo la selección del recurso de Azure Load Testing y la prueba específica que deseas ejecutar. Si estás utilizando YAML: • Agrega un nuevo paso en tu archivo YAML utilizando la tarea de Azure Load Testing que puedes encontrar en el marketplace de Azure DevOps. • Asegúrate de especificar todos los parámetros necesarios, como el nombre del servicio de Azure Load Testing y la prueba específica a ejecutar. Un ejemplo de cómo podría verse el paso en YAML sería: - task: AzureLoadTest@1 inputs: ConnectedServiceName: '<Nombre-de-tu-conexión-de-servicio>' TestId: '<ID-de-tu-prueba-de-carga>' Gating: 'false' # Utiliza 'true' si deseas que la pipeline falle en caso de que la prueba de carga no cumpla con los criterios definidos Paso 5: Configurar los Triggers • Manualmente: Ejecuta la pipeline manualmente cuando lo necesites. • Automáticamente: Configura triggers para ejecutar la pipeline en determinados eventos, como un push al repositorio o una actualización de una rama específica.
y Alertas • Configura la tarea o el paso para que los resultados de la prueba de carga se publiquen en Azure DevOps o se almacenen en un lugar específico para su análisis. • Opcionalmente, establece alertas para notificar al equipo si la prueba de carga falla o no cumple con los criterios establecidos. Paso 7: Ejecutar y Monitorear • Ejecuta la pipeline y monitorea la ejecución de la prueba de carga. • Analiza los resultados para asegurarte de que tu aplicación cumple con los requisitos de rendimiento y escala.
para probar la CPU de una VM: Previamente vamos a crear una VM con Ubuntu, alguna sencilla, y un disco standar. Un ejemplo con AKS – La tecnología subyacente es Chaos Mesh
jmfloreszazo
ttskch
jaguar_imo
bkuhlmann
bob3bob3
ikumatadokoro
fsubal
youkidearitai
kazumain
lovee
sonatard
teamlab
onomax
edds
akosma
bkeepers
chriscoyier
jonyablonski
keavy
bryan
sachag
swwweet
jacobian
palkan
kastner
