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.
Se aplica a esta recomendación de lista de comprobación de eficiencia del rendimiento de Azure Well-Architected Framework:
| PE:06 | Optimice el rendimiento de la carga de trabajo mediante pruebas periódicas en un entorno similar a producción para asegurarse de que la carga de trabajo alcanza los objetivos de rendimiento deseados y logra los objetivos empresariales. |
|---|
Las pruebas de rendimiento son una práctica de pruebas no funcionales que se usa para evaluar cómo se comporta una carga de trabajo en varias condiciones. Le ayuda a identificar la degradación temprana del rendimiento, abordar los problemas de forma proactiva y garantizar la alineación continua con los acuerdos de nivel de servicio.
Al medir los tiempos de respuesta, el rendimiento, el uso de recursos y la estabilidad, recopila pruebas de que la carga de trabajo cumple de forma coherente los objetivos definidos y ofrece el nivel de rendimiento que requiere su empresa.
Las estrategias clave de este artículo se basan en las prácticas de prueba fundamentales descritas en Estrategias de arquitectura de OE:09 para pruebas. Se recomienda revisar primero ese artículo. Las recomendaciones de esta guía están orientadas al rendimiento y se centran en lograr objetivos de rendimiento para que las cargas de trabajo permanezcan alineadas con los objetivos empresariales en constante evolución.
En la tabla siguiente se definen los términos clave de rendimiento que se usan en este artículo.
| Término | Definición |
|---|---|
| Objetivos de rendimiento | Los valores de rendimiento específicos que debe cumplir una carga de trabajo, como el tiempo de respuesta, el rendimiento o el número de usuarios simultáneos. |
| Umbrales de rendimiento | Límites que separan el rendimiento aceptable de un rendimiento inaceptable para una métrica determinada. |
| Presupuesto de rendimiento | Parte de un objetivo de rendimiento global asignado a cada capa o componente de una carga de trabajo. |
| Presupuesto de errores | El nivel permitido de errores o fallos, derivados de los objetivos de nivel de servicio (SLO). |
| Criterios de aceptación | Las condiciones que debe cumplir un resultado de prueba para que la carga de trabajo supere sus requisitos de rendimiento. |
| Experimentación controlada por hipótesis | Método de prueba en el que se indica una predicción sobre el rendimiento, probarlo con una línea base y validarlo con resultados medidos. |
| Línea base de rendimiento | Conjunto de métricas que representan el comportamiento de una carga de trabajo en condiciones normales como se validan mediante las pruebas. |
| Transacciones sintéticas | Solicitudes con scripts que simulan interacciones reales del usuario para medir el rendimiento del sistema en condiciones controladas. |
| Regresión del rendimiento | Disminución del rendimiento en comparación con una línea base establecida, introducida por un cambio en el código, la configuración o la infraestructura. |
| Desfase de rendimiento | Un descenso gradual del rendimiento a lo largo del tiempo que pasa desapercibido sin realizar pruebas periódicas con las líneas base establecidas. |
Establecer objetivos medibles para las pruebas de rendimiento
Los objetivos de rendimiento medibles convierten las expectativas subjetivas en criterios objetivos que puede probar y validar.
Defina los objetivos de rendimiento y asigne presupuestos. Defina y documente objetivos de rendimiento específicos, como el número de usuarios simultáneos que necesita admitir. Asegúrese de que estos objetivos se alinean con los objetivos de nivel de servicio (SLOs), y tradúzcalos en objetivos de prueba medibles.
Asigne presupuestos de rendimiento y errores en diferentes capas de la carga de trabajo. Cuando se producen errores en las pruebas de rendimiento, los presupuestos le ayudarán a identificar qué capa es responsable y dónde centrar los esfuerzos de optimización. Sin presupuestos, las pruebas con errores solo indican que no se cumplen los objetivos de rendimiento, no dónde se encuentra el problema.
Por ejemplo, puede establecer presupuestos de 400 ms para el tiempo de respuesta de la API, 150 ms para consultas de base de datos y un límite de 1% en las solicitudes con error. Cuando se produce un error en una prueba, puede comprobar los resultados de cada capa con respecto a su presupuesto para determinar si el problema es respuestas lentas de api, consultas de base de datos lentas o un pico de errores.
Note
Evite definir SLO antes de comprender los flujos de usuario y los requisitos de rendimiento. Los SLO deben basarse en las necesidades reales de los usuarios y los objetivos empresariales, no en los objetivos arbitrarios.
Defina los criterios de aceptación con umbrales de superación y error claros. Base los criterios de aceptación en las métricas de rendimiento, como la latencia, los tiempos de respuesta, el rendimiento, el uso de recursos, las tasas de error y cualquier otro indicador de rendimiento que se alinee con los objetivos de rendimiento.
Defina umbrales para cada métrica para que las pruebas generen resultados de superación o error claros. Si el SLO requiere 95% de solicitudes para completarse en un plazo de 200 ms, establezca el umbral de tiempo de respuesta de la API en 200 ms en el percentil 95. Cualquier ejecución de prueba en la que el percentil 95 supera los 200 ms es un error.
Inicio temprano y prueba continuamente
El análisis de rendimiento temprano detecta cuellos de botella arquitectónicos antes de que sean costosos de solucionar.
Inicie las pruebas de rendimiento lo antes posible en el ciclo de vida de desarrollo de software de la carga de trabajo. No necesita una aplicación completa para comenzar. Los desarrolladores pueden generar perfiles de código localmente, medir los tiempos de respuesta e identificar operaciones que consumen muchos recursos. Las primeras pruebas informan a las decisiones de diseño, validan las opciones arquitectónicas con respecto a los objetivos de rendimiento e identifican las oportunidades de optimización.
Pruebe continuamente la carga de trabajo a medida que evoluciona para cumplir los nuevos requisitos. Cada cambio de código podría introducir regresiones de rendimiento. Ejecute pruebas periódicamente para detectar estos cambios al principio. Incorpore pruebas de rendimiento en canalizaciones de implementación y ejecute pruebas automatizadas periódicas para detectar el desfase de rendimiento antes de llegar a producción.
Compensación. Las primeras pruebas de rendimiento requieren una infraestructura dedicada y una experiencia especializada, lo que aumenta los costos operativos. Equilibre esta inversión frente al costo de los problemas de rendimiento detectados tarde y los incidentes de producción.
Prueba en condiciones reales
Las pruebas de rendimiento deben coincidir con condiciones reales para que los resultados sean significativos.
Reflejar entorno de producción
El entorno de prueba debe reflejar la producción lo más cerca posible. Adapte su enfoque para el entorno en función del perfil de riesgo de la carga de trabajo.
En el caso de las cargas de trabajo críticas, haga coincidir la producción exactamente entre:
- SKU de computación y configuraciones
- Configuración de escalado automático
- Configuraciones de almacenamiento en caché
- Condiciones de red (latencia, ancho de banda)
- Dependencias externas
En el caso de las cargas de trabajo no críticas, las pruebas en un entorno de reducción vertical que imita la producción pueden proporcionar información útil a un costo menor.
Evite el desfase de configuración. El desfase de configuración puede provocar resultados de pruebas engañosos. Implemente comprobaciones automatizadas para comprobar que el entorno de prueba coincide con la producción. Asegúrese de que las versiones correctas se implementan antes de ejecutar pruebas.
Validación del rendimiento en producción
Los entornos de prueba no pueden replicar completamente las condiciones reales que afectan al rendimiento. Las pruebas de producción exponen problemas que solo aparecen bajo el uso real y proporcionan líneas base precisas para la optimización futura. Algunos requisitos de rendimiento solo se pueden validar en los que los usuarios reales, los datos y la infraestructura se intersecan.
Ejecute pruebas de producción controladas. Programe pruebas durante las horas de poca actividad para comprender cómo su carga de trabajo se comporta cuando los recursos están agotados y se recupera de fallos del sistema.
Las pruebas de producción revelan las características de rendimiento en condiciones reales, entre las que se incluyen:
- Patrones realistas de comportamiento del usuario y volúmenes de datos
- Verdadera latencia de red y variaciones de ancho de banda
- Efectos de distribución geográfica
- Rendimiento y dependencias de api de terceros
- Comportamiento real del almacenamiento en caché y características de infraestructura
Use técnicas de prueba progresivas. Comience con pequeños porcentajes de tráfico y aumente gradualmente. Supervise los tiempos de respuesta, el rendimiento, las tasas de error y el uso de recursos en cada paso. Este enfoque gradual limita el riesgo al identificar el punto de interrupción, revelar cuellos de botella y proporcionar una vista precisa del comportamiento del sistema bajo creciente demanda.
Supervise las pruebas de producción continuamente para encontrar problemas al principio. Implemente medidas de seguridad automatizadas que detengan las pruebas si afectan negativamente a los usuarios, como mecanismos de reversión automatizados y alertas en tiempo real. Estas técnicas garantizan una respuesta rápida y minimizan las interrupciones.
Note
Al ejecutar pruebas de rendimiento controladas en producción, debe asignar capacidad adicional para controlar la carga adicional generada por las pruebas.
Riesgo: Las pruebas de producción afectan directamente a los clientes reales porque pueden crear carga adicional e interrumpir el tráfico. Implemente siempre medidas de seguridad, limite la exposición y tenga planes de reversión listos para minimizar el posible impacto empresarial. Equilibre las ventajas de las pruebas realistas frente al posible impacto empresarial de interrumpir a los usuarios activos.
Validación de cambios con experimentos controlados por hipótesis
Use la experimentación basada en hipótesis para guiar las pruebas de rendimiento. Diseñe experimentos de rendimiento individuales para que generen resultados significativos.
Comience con una hipótesis centrada en el rendimiento de la carga de trabajo y defina criterios de éxito medibles que conducen a decisiones accionables. Por ejemplo, la hipótesis podría ser: "Agregar un índice a la tabla orders reduce el tiempo de consulta en 70% bajo carga máxima". La línea base es el esquema actual y la variante es el esquema con el nuevo índice. Ejecute la misma prueba de carga en ambas versiones. Capture la latencia de consulta, el uso de cpu de la base de datos y el rendimiento y, a continuación, compare los resultados para determinar si la hipótesis es cierta.
Aplicación de varios tipos de pruebas de rendimiento
Las pruebas de rendimiento abarcan una serie de pruebas que evalúan la velocidad, la estabilidad y la escalabilidad en varias condiciones. Cada tipo de prueba tiene como destino distintos aspectos de rendimiento de la carga de trabajo. Descubre información única y permite una evaluación completa que va más allá de las pruebas funcionales.
Use varios tipos de prueba para validar la carga de trabajo desde distintos ángulos. Por ejemplo, las pruebas de esfuerzo encuentran el punto de ruptura bajo la carga máxima, pero solo las pruebas de resistencia revelan pérdidas de memoria que se manifiestan durante horas o días.
Elija los tipos de prueba en función de lo que necesita validar.
En la tabla siguiente se muestra cuándo usar cada tipo de prueba y lo que revela sobre la carga de trabajo. Aunque esta tabla no es una lista exhaustiva, sirve como ejemplo ilustrativo.
| Tipo de prueba | Propósito principal | Cuándo se debe aplicar | Lo que revela | Environment |
|---|---|---|---|---|
| Pruebas de carga | Comprobación de que el sistema controla los volúmenes de usuario esperados en el uso normal y máximo | Inicio temprano, ejecución con frecuencia | Rendimiento de línea base, límites de capacidad, eficacia de escalado | Entorno de ensayo o de producción similar a |
| Pruebas de estrés | Descripción de los límites del sistema y puntos de interrupción | Antes de que el sistema esté listo para producción | Capacidad máxima, modos de error, comportamiento de recuperación | Entorno de pruebas de rendimiento dedicado |
| Pruebas de pico | Asegurarse de que el sistema controla los picos de tráfico repentinos | Empezar temprano, especialmente para aplicaciones orientadas al público | Capacidad de respuesta del escalado automático, control de colas, degradación correcta | Entorno de ensayo o producción |
| Pruebas de resistencia/saturación | Detección de problemas que solo aparecen durante períodos prolongados | Una vez superadas las pruebas de carga iniciales | Pérdida de memoria, agotamiento de recursos, problemas del grupo de conexiones | Entorno similar a producción con asignación de recursos completa |
No intente implementar todos los tipos de prueba inmediatamente. Comience con las pruebas de carga básicas para comprender el rendimiento de la línea base. A medida que identifique riesgos y obtenga experiencia, expanda las pruebas de esfuerzo, las pruebas de pico y las pruebas de resistencia.
Uso de patrones de uso y características de datos reales
Las pruebas con datos realistas proporcionan información precisa sobre el consumo de recursos, el comportamiento del sistema y los problemas de rendimiento ocultos.
Cree diversos conjuntos de datos de prueba que representen varios escenarios, perfiles de usuario y volúmenes de datos. Use variaciones de entrada y selección aleatoria para imitar la diversidad real del usuario. Incluya casos perimetrales que puedan causar problemas de rendimiento, como cargas grandes, consultas complejas o alta simultaneidad.
Los datos de prueba deben ser similares a los datos de producción reales. Use datos sintéticos que tengan características de datos de producción. Reserve conjuntos de datos de producción (anonimizados correctamente) para determinados escenarios, como resaltar comportamientos de administración de datos como la coherencia de transacciones, la latencia y el control de volúmenes.
Simular transacciones sintéticas que imitan flujos de trabajo de usuario reales. Cree scripts de estas transacciones y ejecútelos repetidamente para generar una carga que refleje cómo se utiliza realmente su carga de trabajo.
Los escenarios de prueba deben reflejar patrones de uso reales, como el acceso simultáneo al usuario, los períodos de carga máximo y las secuencias de transacciones específicas. Asegúrese de que los escenarios se alinean con los objetivos empresariales para que los resultados de rendimiento reflejen el valor de usuario verdadero.
Al realizar pruebas bajo carga, incluya llamadas API de terceros reales. La simulación de dependencias externas hace que las pruebas se ejecuten de forma más rápida y predecible, pero oculta los problemas de rendimiento del mundo real. Si la aplicación depende de una API de procesador de pagos, pruebe con llamadas reales para comprender la latencia de un extremo a otro.
Uso de resultados de pruebas para guiar las decisiones de diseño
Los resultados de las pruebas impulsan las decisiones de diseño mediante el establecimiento de referencias confiables y la orientación de los esfuerzos de optimización.
Establezca las medidas de línea base. Las líneas base le ayudan a identificar tendencias y anomalías y si los cambios de optimización proporcionan mejoras. Necesita líneas base confiables para realizar un seguimiento de las tendencias de rendimiento a lo largo del tiempo.
Registre las métricas de rendimiento durante las pruebas iniciales. Esta grabación es la línea base, una instantánea del rendimiento "normal". En ejecuciones posteriores, compare los nuevos resultados con esta línea base para detectar cambios de rendimiento. Considere el impacto del usuario, la frecuencia, el costo de la corrección y el riesgo de criterios de cambio al examinar los datos para comprender el comportamiento del sistema en varias condiciones. Busque patrones que muestren dónde se degrada el rendimiento. Use esta información para priorizar los esfuerzos de optimización.
La optimización es un proceso iterativo y debe estar controlado por datos. En el ciclo de desarrollo, aparte tiempo dedicado para la optimización del rendimiento. Use las líneas base para medir el impacto de los cambios y asegurarse de que ofrecen las mejoras esperadas sin introducir regresiones.
Correlacionar el rendimiento con las métricas empresariales. Conecte las mejoras de rendimiento a los resultados empresariales, como ingresos, involucración del usuario, satisfacción del cliente y tasa de conversión para justificar la inversión continua en la optimización del rendimiento.
Note
Revise y actualice periódicamente las líneas base después de cambios significativos en la carga de trabajo, como cambios de arquitectura, nuevas características o ajustes de escalado. Al realizar esta acción, asegúrese de que los objetivos de rendimiento sigan siendo pertinentes.
Mantener los recursos de prueba alineados con los patrones de uso actuales
Los recursos de prueba de rendimiento contienen conocimientos críticos sobre el comportamiento esperado de la carga de trabajo, los umbrales de rendimiento aceptables y los patrones de tráfico realistas.
Organice conjuntos de pruebas por tipo. Mantenga pruebas de carga, pruebas de esfuerzo y pruebas de resistencia en conjuntos independientes. No los mezcles. Cada tipo tiene diferentes requisitos de configuración, duraciones de ejecución y criterios de éxito. Los conjuntos organizados facilitan la ejecución de pruebas dirigidas, comparan los resultados entre ejecuciones y mantienen cada conjunto de forma independiente.
Actualice los datos de prueba con regularidad. Los datos de prueba obsoletos provocan resultados poco realistas. Vuelva a generar datos de prueba para reflejar las características actuales de los datos de producción cada vez que cambie el modelo de datos, los volúmenes de datos crezcan o cambien los datos demográficos del usuario.
Revise los escenarios de prueba a medida que evoluciona la carga de trabajo. Programe revisiones periódicas para asegurarse de que los escenarios siguen reflejando el uso real. Los escenarios se vuelven obsoletos debido a:
- El comportamiento del usuario cambia con el tiempo
- Los patrones de tráfico cambian a medida que crece la base de usuarios
- Las nuevas características presentan diferentes patrones de uso
- Escalado de infraestructura para cumplir los nuevos requisitos de capacidad
Facilitación de Azure
Azure Pipelines permite integrar las pruebas de rendimiento en la canalización de CI/CD. Puede agregar pruebas de carga como paso en la canalización para validar el rendimiento y la escalabilidad de las aplicaciones.
Azure Chaos Studio le ayuda a insertar errores reales en la aplicación para que pueda ejecutar experimentos de inyección de errores controlados. Los experimentos le ayudan a medir, comprender y mejorar la resistencia de la aplicación y el servicio en la nube.
Azure Load Testing es un servicio de pruebas de carga que genera una carga a gran escala en cualquier aplicación. Load Testing proporciona funcionalidades para automatizar las pruebas de carga e integrarlas en el flujo de trabajo de integración continua y entrega continua (CI/CD). Puede definir criterios de prueba, como el tiempo medio de respuesta o los umbrales de error, y detener automáticamente las pruebas de carga en función de condiciones de error específicas. Load Testing ofrece un panel que proporciona actualizaciones dinámicas y métricas detalladas de recursos de los componentes de la aplicación de Azure durante una prueba de carga. Puede analizar los resultados de las pruebas, identificar cuellos de botella de rendimiento y comparar varias ejecuciones de pruebas para comprender las regresiones de rendimiento a lo largo del tiempo.
Azure Monitor es una solución de supervisión completa para recopilar, analizar y responder a la telemetría de los entornos locales y en la nube. Application Insights es una extensión de Monitor que proporciona características de APM. Puede usar Application Insights para supervisar las aplicaciones durante el desarrollo y las pruebas y también en producción.
Vínculos relacionados
- Recomendaciones para pruebas de seguridad
- Recomendaciones para diseñar una estrategia de pruebas de confiabilidad
Lista de comprobación de eficiencia del rendimiento
Consulte el conjunto completo de recomendaciones.