Compartir vía

Azure Load Testing con complementos personalizados

  • Artículo

Ideas de solución

En este artículo se describe una idea de solución. El arquitecto de la nube puede usar esta guía para ayudar a visualizar los componentes principales de una implementación típica de esta arquitectura. Use este artículo como punto de partida para diseñar una solución bien diseñada que se adapte a los requisitos específicos de la carga de trabajo.

Esta solución proporciona instrucciones sobre cómo usar Azure Load Testing, un servicio que le permite ejecutar scripts de Apache JMeter y complementos personalizados para simular comportamientos de usuarios y dispositivos. Esta solución también explica cómo diseñar indicadores clave de rendimiento (KPI) y desarrollar un panel para supervisar y analizar los resultados de la prueba de carga en una aplicación de ejemplo con Azure Functions y Azure Event Hubs. En el artículo se da por supuesto que el usuario está familiarizado hasta cierto punto con JMeter, sus complementos y complementos personalizados, así como con Azure Functions y Event Hubs.

Arquitectura

Para realizar pruebas de carga, necesita un plan de prueba, que es un conjunto de instrucciones que indica a JMeter lo que debe hacer durante la prueba. El plan de prueba puede incluir varios escenarios de prueba, cada uno con diferentes opciones y configuraciones. Por ejemplo, podría haber una situación en que se simulase un solo usuario que accede a una aplicación web y otra situación en que se simulase que varios usuarios acceden simultáneamente a la misma aplicación.

El plan de prueba también puede incluir varios casos de prueba, cada uno con diferentes opciones y configuraciones. En nuestro caso, se supone que hay un dispositivo que informa de la temperatura y la humedad durante un período de tiempo determinado. El dispositivo envía los datos a un centro de eventos de Azure. El centro de eventos desencadena una función de Azure que se encarga del procesamiento de los datos y, a continuación, envía datos a otros servicios descendentes, como Azure SQL Database. La función de Azure es el servicio que queremos probar. El plan de prueba está diseñado para simular el comportamiento del dispositivo y enviar datos al centro de eventos.

Diagrama de una arquitectura de ejemplo para pruebas de carga.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

En este ejemplo, el flujo de datos es el siguiente:

  1. Un dispositivo simulado envía datos a un centro de eventos por medio del agente de Azure Load Testing. Cualquier comportamiento del dispositivo se puede simular mediante complementos personalizados de JMeter. El agente de Azure Load Test se encarga de enviar datos al centro de eventos después de ejecutar el complemento personalizado para dispositivos simulados de cualquier tipo.
  2. El centro de eventos desencadena una función de Azure que se encarga del procesamiento de los datos y, a continuación, envía datos a otros servicios descendentes, como Azure SQL Database y Azure Digital Twins.
  3. El servicio Azure Monitor se usa para supervisar la función de Azure y Event Hubs.
  4. El servicio Azure Load Testing recopila los datos del servicio Azure Monitor y, a continuación, los muestra en un panel.

Componentes

En este ejemplo, se usan los componentes siguientes:

  • Azure Load Testing: Azure Load Testing permite ejecutar scripts de Apache JMeter y complementos personalizados para simular comportamientos de usuarios y dispositivos. Proporciona una interfaz basada en web para administrar y ejecutar pruebas de carga y un conjunto de API que se pueden usar para automatizar el proceso. Azure Load Testing es un servicio totalmente administrado, lo que significa que no es necesario preocuparse por administrar servidores o infraestructuras. Puede cargar los scripts de JMeter y los complementos personalizados, y Azure Load Testing se encarga del resto.
  • Azure Event Hubs: Azure Event Hubs es un servicio de procesamiento de eventos basado en la nube que se puede usar para recopilar, procesar y analizar eventos y transmitir datos de varios orígenes en tiempo real. Event Hubs admite varios protocolos, como AMQP (Advanced Message Queuing Protocol), HTTPS, protocolo Kafka, MQTT (Message Queuing Telemetry Transport) y AMQP sobre WebSockets. La elección del protocolo adecuado depende de varios factores, como el tipo de datos con los que se trabaja, los requisitos específicos de la aplicación y las funcionalidades y limitaciones de los propios protocolos.
  • Azure Functions: Azure Functions es un servicio de proceso sin servidor que permite ejecutar código sin tener que administrar servidores ni la infraestructura. Es compatible con varios lenguajes de programación, como C#, F#, Java, JavaScript, PowerShell, Python y TypeScript. Azure Functions se puede usar para procesar eventos y datos de streaming desde Event Hubs, así como otros orígenes, como Azure Storage y Azure Cosmos DB.
  • GUI de JMeter: la GUI de JMeter es una herramienta de prueba de carga de código abierto que se usa principalmente para probar el rendimiento de aplicaciones web. En un principio se desarrolló para probar aplicaciones web. Pero también se puede usar para probar otros tipos de aplicaciones, como servicios web SOAP y REST, servidores FTP y bases de datos.
  • Azure Monitor: Azure Monitor ofrece funcionalidades de supervisión y alerta para los recursos de Azure. También permite supervisar el rendimiento y el estado de las aplicaciones y la infraestructura subyacente. Azure Monitor se puede usar para supervisar Event Hubs y funciones de Azure, así como otros servicios de Azure, como Azure Storage y Azure Cosmos DB.

Detalles del escenario

Azure Load Testing permite tomar un script de Apache JMeter existente y usarlo para ejecutar una prueba de carga a escala de la nube sobre cualquier recurso de Azure.

JMeter permite a los evaluadores crear y ejecutar pruebas de carga, pruebas de esfuerzo y pruebas funcionales. Simula el acceso simultaneo de varios usuarios a una aplicación web, lo que permite a los evaluadores identificar posibles cuellos de botella de rendimiento u otros problemas que pueden surgir en caso de cargas pesadas. JMeter se puede usar para medir varias métricas de rendimiento, como el tiempo de respuesta, el rendimiento y la tasa de errores.

JMeter usa una interfaz basada en GUI para permitir a los usuarios crear planes de prueba, que pueden incluir varios escenarios de prueba, cada uno con opciones y configuraciones diferentes. Los evaluadores también pueden personalizar JMeter mediante complementos o escribiendo código personalizado, lo que les permite ampliar su funcionalidad más allá de las opciones preconfiguradas. Los complementos pueden ayudarnos a trabajar con servicios que usan protocolos que no son HTTP, como AMQP y Websocket.

Aunque JMeter ofrece una gran variedad de características y funciones para las pruebas de carga, puede haber casos de uso o requisitos específicos que no queden cubiertos por la funcionalidad integrada. Al desarrollar complementos personalizados, los evaluadores pueden agregar funciones nuevas o personalizar las características existentes para que se adapten mejor a sus necesidades.

Por ejemplo, se podría desarrollar un complemento personalizado para simular un tipo de comportamiento específico del usuario o para generar datos de prueba más realistas. Además, se pueden desarrollar complementos personalizados para integrar JMeter con otras herramientas o sistemas, como herramientas de registro e informes o canalizaciones de integración e implementación continuas. Los complementos personalizados pueden ayudar a optimizar el proceso de prueba y facilitar la incorporación de pruebas de carga en el flujo de trabajo general de desarrollo de software. En general, permiten a los evaluadores adaptar JMeter a sus necesidades específicas y mejorar la precisión y eficacia de sus actividades de pruebas de carga.

En este ejemplo, se supone que hay un dispositivo que informa de la temperatura y la humedad durante un período de tiempo establecido. Podemos simular este comportamiento sencillo mediante un complemento JMeter personalizado. En la implementación actual del complemento personalizado que se proporciona aquí, generamos datos aleatorios mediante una plantilla proporcionada. Sin embargo, el complemento puede contener cualquier comportamiento complejo posible para cualquier dispositivo. En este ejemplo, el dispositivo envía los datos a un centro de eventos en Azure. El centro de eventos desencadena una función de Azure que se encarga del procesamiento de los datos y, a continuación, envía datos a otros servicios descendentes, como Azure SQL Database. La función de Azure es el servicio que queremos probar. El plan de prueba está diseñado para simular el comportamiento del dispositivo y enviar datos al centro de eventos.

Posibles casos de uso

El uso de Azure Load Testing con complementos personalizados puede resultar útil en varios escenarios como, por ejemplo:

  • Probar el rendimiento de una aplicación que usa protocolos que no son HTTP, como AMQP y Websocket.
  • Probar el rendimiento de una aplicación que usa un protocolo personalizado.
  • Probar el rendimiento de una aplicación que usa un SDK que no es de Microsoft.
  • Simular un tipo específico de comportamiento de usuario o dispositivo o generar datos de prueba más realistas.

Complementos personalizados

Los complementos personalizados en el contexto de JMeter son componentes de software que se pueden agregar a JMeter para ampliar su funcionalidad más allá de las opciones preconfiguradas. Los usuarios o desarrolladores que no son de Microsoft pueden desarrollar complementos personalizados para agregar nuevas características, funciones o integraciones a JMeter. Se pueden desarrollar complementos personalizados mediante el lenguaje de programación Java y el Kit de desarrollo de complementos de JMeter (PDK). El PDK proporciona un conjunto de herramientas y API que facilitan la creación de nuevos complementos, incluidos elementos de GUI, agentes de escucha y muestreadores.

Los complementos personalizados pueden aportar una gran variedad de funcionalidades a JMeter. También pueden integrar JMeter con otros sistemas, como herramientas de registro e informes, o permitir el uso de otros orígenes de datos para los datos de prueba. En general, los complementos personalizados permiten a los usuarios ampliar JMeter para cubrir sus necesidades específicas y mejorar la precisión y eficacia de sus actividades de pruebas de carga.

Para implementar un muestreador personalizado para Event Hubs en JMeter, siga las instrucciones indicadas en Complementos de Azure Load Testing. Una vez implementado el muestreador personalizado, puede usarlo en el plan de prueba de JMeter en Azure Load Test igual que cualquier otro muestreador.

Se puede implementar un plan de prueba mediante un grupo de subprocesos que controla el número de subprocesos (usuarios virtuales y dispositivos) para ejecutar un escenario específico. Cada grupo de subprocesos puede tener una configuración diferente para el número de subprocesos, el período de inicialización, el recuento de bucles y la duración. Los grupos de subprocesos se pueden ejecutar secuencialmente o en paralelo, según la configuración del plan de prueba y los requisitos de la aplicación. Puede agregar el muestreador a un grupo de subprocesos, definir sus parámetros y configurarlo según sea necesario. Los muestreadores personalizados pueden ser herramientas eficaces en JMeter, ya que permiten simular escenarios complejos y solicitudes que los muestreadores integrados no admiten.

Creación de un script de Apache JMeter con un complemento personalizado

En esta sección, creará un script de prueba de JMeter de ejemplo para cargar una aplicación con Event Hubs.

Para crear un script de prueba de JMeter de ejemplo:

  1. Cree un archivo LoadTest.jmx en el equipo local:

    touch LoadTest.jmx

  2. Abra el archivo LoadTest.jmx en un editor de texto y pegue el siguiente fragmento de código en el archivo. Este script simula una prueba de carga de 36 máquinas virtuales que envían eventos simultáneamente a un centro de eventos y tarda 10 minutos en completarse:

    <?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

    La implementación de com.microsoft.eventhubplugin.EventHubPluginGui y com.microsoft.eventhubplugin.EventHubPlugin está disponible en Ejemplos de Azure.

  3. En el archivo, establezca como valor del nodo eventHubConnectionVarName el nombre de variable que especifica el host de la cadena de conexión de Event Hubs. Por ejemplo, si desea que la variable de entorno que almacene la cadena de conexión de Event Hubs sea EventHubConnectionString, establezca esta variable en EventHubConnectionString y, a continuación, establezca el valor de la variable de entorno.

    Importante

    Asegúrese de que el valor de EventHubConnectionString se haya establecido como parte del proceso de creación de pruebas de carga de Azure antes de ejecutar el script de prueba de carga.

  4. En el archivo, establezca como valor del nodo eventHubName el nombre del centro de eventos, como por ejemplo telemetry-data-changed-eh.

  5. Establezca como valor del nodo liquidTemplateFileName el archivo que contiene el mensaje que se envía al centro de eventos. Por ejemplo, cree un archivo denominado StreamingDataTemplate.liquid como:

    {
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}

    En este ejemplo, la carga del mensaje del centro de eventos es un objeto JSON con tres propiedades, como MachineId, Temperature y Humidity, donde MachineId es un identificador generado aleatoriamente con una longitud de 27 y Temperature y Humidity son enteros aleatorios inferiores a 100. Este archivo sigue una sintaxis de plantilla Liquid. La plantilla Liquid es un lenguaje de plantillas popular que se usa en varios marcos de desarrollo web. Las plantillas Liquid permiten a los desarrolladores crear contenido dinámico que se pueda actualizar y modificar fácilmente. Permiten insertar variables, condiciones, bucles y otros elementos dinámicos en los mensajes del centro de eventos. La sintaxis es sencilla y hay un montón de recursos en línea disponibles para ayudarle a comenzar. En general, las plantillas Liquid ofrecen una manera eficaz y flexible de crear mensajes dinámicos y personalizables.

  6. Guarde y cierre el archivo.

    Importante

    No incluya ningún dato personal en el nombre del muestreador en el script de JMeter. Los nombres de los muestreadores aparecen en el panel de resultados de las pruebas de Azure Load Testing. Hay disponible un ejemplo de una plantilla Liquid junto con el archivo de script JMeter para descargar en Ejemplos de Azure

Ejecución de la prueba de carga mediante el nuevo complemento

Cuando Azure Load Testing inicia la prueba de carga, primero implementa el script de JMeter junto con todos los demás archivos en instancias del motor de prueba y, a continuación, inicia la prueba de carga como se indica en Personalización de una prueba de carga con complementos de Apache JMeter y Azure Load Testing. Antes de ejecutar la prueba, vaya a la pestaña de parámetros, defina EventHubConnectionString y proporcione la cadena de conexión al centro de eventos.

Captura de pantalla que muestra los parámetros de la prueba.

Configuración de pruebas de rendimiento para el entorno

En cualquier prueba de rendimiento, es importante disponer de un entorno similar al entorno de producción. En este ejemplo, se usa el siguiente entorno para las pruebas de rendimiento con el fin de comprender mejor la capacidad del sistema y el rendimiento del sistema.

Según la arquitectura del ejemplo, se podrían usar los siguientes servicios para las pruebas de rendimiento:

Service Configuración
Eventhub Premium con una unidad de procesamiento (PU).
Función de Azure Linux con plan Premium (EP1): 210 ACU, 3,5 GB de memoria y 1 vCPU equivalente Standard_D1_v2
Region Este de EE. UU.

La elección del nivel de servicio adecuado para cualquier servicio de Azure, incluidos Event Hubs y Azure Functions, es un proceso complejo que depende de muchos factores. Para más información, consulte Precios de Azure Event Hubs y Precios de Azure Functions.

Diseño de KPI para pruebas de rendimiento

Para poder diseñar indicadores clave de rendimiento (KPI) para las pruebas de rendimiento, necesita dos cosas: los requisitos empresariales y la arquitectura del sistema. Los requisitos empresariales le indican qué KPI desea medir, como el tiempo de respuesta, el rendimiento o la tasa de errores. La arquitectura del sistema le indica cómo probar el rendimiento de cada componente, como servidores web, bases de datos o API. También le ayuda a elegir la mejor estrategia de pruebas de rendimiento, como pruebas de carga, pruebas de esfuerzo o pruebas de resistencia.

En este ejemplo, los requisitos empresariales son:

  • El sistema debe poder gestionar 1000 solicitudes por segundo.
  • La fiabilidad del sistema debe ser superior a 0,99.
  • El sistema debe poder gestionar 1000 dispositivos simultáneos que proporcionen su información de datos personales.
  • Especificar la capacidad máxima del sistema por lo que respecta al número de dispositivos que se pueden admitir. Por ejemplo, ¿el sistema con el triple de la capacidad actual admite 1000 dispositivos simultáneos?

Según estos requisitos, los KPI para las pruebas de rendimiento podrían ser:

KPI Descripción
RPS Solicitudes por segundo para un centro de eventos
LOAD Número de cargas o solicitudes enviadas al centro de eventos durante las pruebas de rendimiento
IR Número de ejecuciones de funciones o tasa de ingesta
RT Promedio de tiempo para el tiempo de ejecución de Azure Functions
AMU Uso medio de memoria para Azure Functions
SR Tasa de éxito de todas las ejecuciones de funciones
ARS Promedio de tiempo de respuesta del servicio de bajada (por ejemplo, SQL Server o un microservicio)
DF Recuento de errores de dependencia, incluidos los errores internos de funciones de Azure
MRPS Número máximo de RPS sin trabajo pendiente en el centro de eventos (capacidad del sistema)

Medición de KPI

Para medir los KPI, debe disponer de una estrategia de pruebas de rendimiento. La estrategia define el enfoque de pruebas de rendimiento para cada componente. En este ejemplo, se usa la siguiente estrategia de pruebas de rendimiento:

  • Event Hubs: el enfoque de pruebas de rendimiento para el centro de eventos consiste en enviar muchos mensajes al centro de eventos y, a continuación, medir los valores de RPS y LOAD. RPS es el número de mensajes que se envían al centro de eventos por segundo. LOAD es el número total de mensajes que se envían al centro de eventos durante las pruebas de rendimiento. El servicio Azure Load Testing puede medir RPS y LOAD.
  • Azure Functions: el enfoque de pruebas de rendimiento para Azure Functions consiste en medir las métricas siguientes:
    • IR es el número de ejecuciones de funciones o la tasa de ingesta.
    • RT es el tiempo medio para el tiempo de ejecución de la función de Azure.
    • AMU es el uso medio de memoria para Azure Functions.
    • SR es la tasa de éxito de todas las ejecuciones de funciones.
    • ARS es el tiempo medio de respuesta del servicio de bajada.
    • DF es el recuento de errores de dependencia, incluidos los errores internos de funciones de Azure.
    • El servicio Azure Monitor puede medir los valores de AMU, ARS y DF, pero no IR, RT o SR.

Para medir los KPI mediante el servicio Azure Monitor, es necesario habilitar Application Insights para Azure Functions. Para obtener más información, consulte Habilitación de la integración de Application Insights.

Después de habilitar el servicio Azure Monitor, puede usar las siguientes consultas para medir los KPI:

  • IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
  • RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
  • SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Ejemplo del panel de Azure Monitor

A continuación se ofrece un ejemplo del panel de Azure Monitor que muestra los KPI de Azure Functions en función de las consultas:

Ejemplos de capturas de pantalla del panel de Azure Monitor.

Conclusión

En este artículo, ha aprendido a diseñar KPI y a desarrollar un panel para Azure Load Test. También ha aprendido a usar complementos personalizados en JMeter para realizar pruebas de carga en Azure Functions integradas con Event Hubs. Puede usar el mismo método para realizar pruebas de carga en otros servicios de Azure. También puede configurar una canalización de integración y entrega continuas (CI/CD) para los scripts de prueba de carga mediante Azure DevOps.

Para obtener más información, consulte Azure Load Testing.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes