Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Obtenga información sobre los conceptos y componentes clave de Azure Load Testing. Esta información puede ayudarle a configurar de forma más eficaz una prueba de carga para identificar problemas de rendimiento en la aplicación.
Conceptos generales de las pruebas de carga
Obtenga información sobre los conceptos clave relacionados con la ejecución de pruebas de carga.
Usuarios virtuales
Un usuario virtual ejecuta un caso de prueba determinado en la aplicación de servidor y se ejecuta independientemente de otros usuarios virtuales. Puede usar varios usuarios virtuales para simular conexiones simultáneas a la aplicación de servidor.
Apache JMeter también hace referencia a los usuarios virtuales como subprocesos. En el script de prueba de JMeter, un elemento de grupo de subprocesos le permite especificar el grupo de usuarios virtuales. Obtenga información sobre los grupos de subprocesos en la documentación de Apache JMeter.
Locust hace referencia a usuarios virtuales como usuarios. Puede especificar los usuarios necesarios para la prueba en la interfaz web, como argumento de línea de comandos, a través de una variable de entorno o a través de un archivo de configuración. Para obtener más información, consulte opciones de configuración en la documentación de Locust.
El número total de usuarios virtuales para la prueba de carga depende del número de usuarios virtuales del script de prueba y del número de instancias del motor de pruebas.
Para las pruebas de carga basadas en JMeter, la fórmula es: Total de usuarios virtuales = (usuarios virtuales en el archivo JMX) * (número de instancias del motor de pruebas).
Puede lograr el número de usuarios virtuales de destino configurando el número de instancias del motor de pruebas, el número de usuarios virtuales en el script de prueba o una combinación de ambos.
En el caso de las pruebas de carga basadas en Locust, el número total de usuarios virtuales es el número de usuarios especificados a través de cualquiera de las opciones de configuración. A continuación, puede configurar el número de instancias del motor de pruebas necesarias para generar el número total de usuarios.
Tiempo de aceleración
El tiempo de aumento es la cantidad de tiempo que se tarda en llegar al número completo de usuarios virtuales para la prueba de carga. Si el número de usuarios virtuales es 20 y el tiempo de rampa es de 120 segundos, se tarda 120 segundos en llegar a los 20 usuarios virtuales. Cada usuario virtual iniciará 6 (120/20) segundos después de iniciar el usuario anterior.
Para Locust, puede configurar el aumento mediante la tasa de generación. La tasa de generación es el número de usuarios añadidos por segundo. Por ejemplo, si el número de usuarios es 20 y la tasa de desove es 2, se agregarán 2 usuarios cada segundo y se tardarán 10 segundos en llegar a los 20 usuarios.
Tiempo de respuesta
El tiempo de respuesta de una solicitud individual, o el tiempo transcurrido en JMeter, es el tiempo total de justo antes de enviar la solicitud a justo después de recibir la última respuesta. El tiempo de respuesta no incluye el tiempo para representar la respuesta. Cualquier código de cliente, como JavaScript, no se procesa durante la prueba de carga.
Latencia
La latencia de una solicitud individual es el tiempo total de justo antes de enviar la solicitud a justo después de recibir la primera respuesta. La latencia incluye todo el procesamiento necesario para ensamblar la solicitud y ensamblar la primera parte de la respuesta.
Solicitudes por segundo (RPS)
Las solicitudes por segundo (RPS) o el rendimiento son el número total de solicitudes a la aplicación de servidor que la prueba de carga genera por segundo.
La fórmula es: RPS = (número de solicitudes) / (tiempo total en segundos).
La hora se calcula desde el principio del primer ejemplo hasta el final del último ejemplo. Este tiempo incluye cualquier intervalo entre las muestras, por ejemplo, si el script de prueba contiene temporizadores.
Otra manera de calcular el RPS se basa en la latencia media de la aplicación y el número de usuarios virtuales. Para simular un número específico de RPS con una prueba de carga, dada la latencia de la aplicación, puede calcular el número necesario de usuarios virtuales.
La fórmula es: Usuarios virtuales = (RPS) * (latencia en segundos).
Por ejemplo, dada una latencia de aplicación de 20 milisegundos (0,02 segundos), para simular 100 000 RPS, debe configurar la prueba de carga con 2000 usuarios virtuales (100 000 * 0,02).
Componentes de Azure Load Testing
Obtenga información sobre los conceptos y componentes clave de Azure Load Testing. En el diagrama siguiente se proporciona información general sobre cómo se relacionan los distintos conceptos entre sí.
Recurso de Load Testing
El recurso de pruebas de carga de Azure es el recurso de nivel superior para las actividades de prueba de carga. Este recurso proporciona un lugar centralizado para ver y administrar pruebas de carga, resultados de pruebas y artefactos relacionados.
Al crear un recurso de prueba de carga, especifique su ubicación, que determina la ubicación de los motores de prueba. Azure Load Testing cifra automáticamente todos los artefactos en tu recurso. Puede elegir entre claves administradas por Microsoft o usar sus propias claves administradas por el cliente para el cifrado.
Para ejecutar una prueba de carga para la aplicación, agregue una prueba al recurso de pruebas de carga. Un recurso puede contener cero o más pruebas.
Puede usar el control de acceso basado en rol de Azure para conceder acceso al recurso de prueba de carga y a los artefactos relacionados.
Azure Load Testing permite usar identidades administradas con diversos fines, como el acceso a Azure Key Vault para almacenar los parámetros o certificados del secreto de prueba de carga, el acceso a las métricas de Azure Monitor para configurar criterios de error o simular flujos de autenticación basados en identidades administradas.
Prueba
Una prueba describe la configuración de prueba de carga de la aplicación. Agregue una prueba a un recurso de prueba de carga de Azure existente.
Una prueba contiene un plan de prueba, que describe los pasos para invocar el punto de conexión de la aplicación. Puede definir el plan de prueba de una de estas tres maneras:
- Cargue un script de prueba de JMeter.
- Cargue un script de prueba de Locust.
- Especifique la lista de puntos finales URL para probar.
Azure Load Testing admite todos los protocolos de comunicación compatibles con JMeter y Locust, no solo los puntos de conexión basados en HTTP. Por ejemplo, es posible que desee leer o escribir en una base de datos o cola de mensajes en el script de prueba.
Actualmente, Azure Load Testing no admite otros marcos de pruebas que Apache JMeter y Locust.
La prueba también especifica los valores de configuración para ejecutar la prueba de carga:
- Parámetros de prueba de carga, como variables de entorno, secretos y certificados.
- Cargue la configuración para escalar horizontalmente la prueba de carga en varias instancias del motor de prueba.
- Criterios de fallo para determinar cuándo la prueba debe aprobar o reprobar.
- Configuración de supervisión para configurar la lista de componentes de la aplicación de Azure y las métricas de recursos que se van a supervisar durante la ejecución de pruebas.
Además, puede cargar archivos de datos de entrada CSV y probar archivos de configuración en la prueba de carga.
Al iniciar una prueba, Azure Load Testing implementa el script de prueba, los archivos relacionados y la configuración en las instancias del motor de pruebas. A continuación, las instancias del motor de pruebas inician el script de prueba para simular la carga de la aplicación.
Cada vez que inicie una prueba, Azure Load Testing crea una ejecución de prueba y la asocia a la prueba.
Ejecución de pruebas
Una ejecución de prueba representa una ejecución de una prueba de carga. Al ejecutar una prueba, el test contiene una copia de los valores de configuración de la prueba asociada.
Una vez completada la ejecución de la prueba, puede ver y analizar los resultados de la prueba de carga en el panel de Azure Load Testing en Azure Portal.
Como alternativa, puede descargar los registros de prueba y exportar el archivo de resultados de la prueba.
Importante
Al actualizar una prueba, las ejecuciones de pruebas existentes no heredan automáticamente la nueva configuración de la prueba. La nueva configuración solo se utiliza en nuevas ejecuciones de pruebas cuando ejecutas la prueba . Si vuelve a ejecutar una ejecución de prueba existente , se usa la configuración original de la ejecución de prueba.
Motor de pruebas
Un motor de pruebas es una infraestructura informática administrada por Microsoft que ejecuta el script de prueba. Las instancias del motor de pruebas ejecutan el script de prueba en paralelo. Puede escalar horizontalmente la prueba de carga configurando el número de instancias de motores de pruebas. Obtenga información sobre cómo configurar el número de usuarios virtuales o simular un número de solicitudes de destino por segundo.
Los motores de prueba se hospedan en la misma ubicación que el recurso de Azure Load Testing. Puede configurar la región de Azure al crear el recurso de prueba de carga de Azure.
Azure Load Testing usa máquinas virtuales de tamaño Standard_D4d_v4 con cuatro vCPU, 16 GB de memoria y sistema operativo Linux de Azure como motores de prueba. Para las pruebas basadas en JMeter, los motores de prueba usan JDK 21 y Apache JMeter versión 5.6.3. Para las pruebas basadas en Locust, los motores de prueba usan Python 3.9.19 y Locust versión 2.33.2.
Mientras se ejecuta el script de prueba, Azure Load Testing recopila y agrega los registros del marco de pruebas de todas las instancias del motor de pruebas. Puede descargar los registros para analizar errores durante la prueba de carga.
Componente de aplicación
Al ejecutar una prueba de carga para una aplicación hospedada en Azure, puede supervisar las métricas de recursos de los distintos componentes de la aplicación de Azure (métricas del lado servidor). Mientras se ejecuta la prueba de carga y, después de la finalización de la prueba, puede supervisar y analizar las métricas de recursos en el panel de Azure Load Testing.
Al crear o actualizar una prueba de carga, puede configurar la lista de componentes de la aplicación que supervisará Azure Load Testing. Puede modificar la lista de métricas de recursos predeterminadas para cada componente de la aplicación.
Obtenga más información sobre qué Tipos de recursos de Azure admite Azure Load Testing.
Métricas
Durante una prueba de carga, Azure Load Testing recopila métricas sobre la ejecución de la prueba. Hay dos tipos de métricas:
Los motores de prueba notifican las Métricas del lado cliente. Estas métricas incluyen el número de usuarios virtuales, el tiempo de respuesta de la solicitud, el número de solicitudes con error o el número de solicitudes por segundo. Puede definir criterios de error de prueba en función de estas métricas del lado cliente.
Las métricas del lado servidor están disponibles para las aplicaciones hospedadas en Azure y proporcionan información sobre los componentes de la aplicación de Azure. Azure Load Testing se integra con Azure Monitor, incluido Application Insights y Container Insights, para capturar detalles de los servicios de Azure. Dependiendo del tipo de servicio, hay diferentes métricas disponibles. Por ejemplo, las métricas pueden ser para el número de lecturas de base de datos, el tipo de respuestas HTTP o el consumo de recursos de contenedor. También puede definir criterios de error de prueba en función de estas métricas del lado servidor.
Contenido relacionado
Ahora conoce los conceptos clave de Azure Load Testing para empezar a crear una prueba de carga.
- Obtenga información sobre cómo funciona Azure Load Testing.
- Aprenda a crear y ejecutar una prueba de carga basada en direcciones URL para un sitio web.
- Aprenda a identificar un cuello de botella de rendimiento en una aplicación de Azure.
- Aprenda a configurar pruebas de regresión automatizadas con CI/CD.