Lista de comprobación: prueba de la eficacia del rendimiento

¿Se ha probado el rendimiento, la escalabilidad y la resistencia de la aplicación?

Las pruebas de rendimiento ayudan a mantener los sistemas correctamente y a corregir los defectos antes de que lleguen a los usuarios del sistema. Forman parte del pilar de eficacia del rendimiento según el Marco de buena arquitectura de Microsoft Azure.

Las pruebas de rendimiento son el supraconjunto de las pruebas de carga y de esfuerzo. El objetivo principal de las pruebas de rendimiento es validar el comportamiento de referencia de la aplicación.

Las pruebas de carga validan la escalabilidad de la aplicación; para ello, se aumenta de forma rápida o gradual la carga en la aplicación hasta que se alcanza un umbral.

Prueba de esfuerzo es un tipo de prueba negativa, que implica varias actividades para sobrecargar los recursos existentes y quitar componentes. Esta prueba le permite comprender la resistencia general y cómo responde la aplicación a los problemas.

Use la siguiente lista de comprobación para revisar la arquitectura de la aplicación desde la perspectiva de la prueba de rendimiento.

Pruebas de rendimiento

• Asegúrese de realizar pruebas de rendimiento sólidas en las que todo el equipo comparta la responsabilidad. Para implementar correctamente pruebas de rendimiento significativas, se necesitan varios recursos. Tenga en cuenta que no se trata solo de que un desarrollador o un analista de control de calidad lleve a cabo algunas pruebas en su máquina local. Las pruebas de rendimiento necesitan un entorno de prueba (también conocido como banco de pruebas) en el que se puedan ejecutar las pruebas sin que interfieran con los datos y los entornos de producción. Las pruebas de rendimiento requieren la participación y el compromiso de los desarrolladores, arquitectos, administradores de bases de datos y administradores de red.

• Planeamiento de capacidad Durante una prueba de rendimiento, la empresa debe comunicar cualquier fluctuación en la carga esperada. La carga puede verse afectada por sucesos mundiales, como cambios políticos, económicos o meteorológicos; por iniciativas de marketing, como ventas o promociones; o por sucesos estacionales, como periodos festivos. Debe probar las variaciones de carga antes de estos eventos, incluidos los inesperados, para asegurarse de que la aplicación pueda escalarse. Además, debe asegurarse de que todas las regiones se pueden escalar adecuadamente para admitir la carga total, en caso de que se produzca un error en una región.

• Identifique el camino que hay que seguir para aprovechar las pruebas existentes o crear otras. Existen diferentes tipos de pruebas de rendimiento: prueba de carga, prueba de esfuerzo, prueba de API, prueba de cliente/explorador, etc. También es importante que comprenda y articule los distintos tipos de pruebas, junto con sus ventajas y desventajas para el cliente.

• Realice pruebas en todas las fases del ciclo de vida de desarrollo e implementación. Se deben probar el código de aplicación, la automatización de la infraestructura y la tolerancia a errores. Esto puede garantizar que la aplicación tendrá el rendimiento previsto en todas las situaciones. Es aconsejable realizar las pruebas lo suficientemente pronto en el ciclo de vida de la aplicación para detectar y corregir los errores. Los errores son más baratos de reparar cuando se detectan pronto y pueden ser caros o imposibles de corregir más adelante. Para obtener más información, consulte Pruebas de la aplicación y el entorno de Azure.

• Evite experimentar un rendimiento deficiente en las pruebas. Dos subconjuntos de pruebas de rendimiento, las pruebas de carga y las pruebas de esfuerzo, pueden determinar el límite superior y el punto de error máximo, respectivamente, de la capacidad de la aplicación. Al realizar estas pruebas, puede determinar la infraestructura necesaria para admitir las cargas de trabajo previstas.

• Planee un búfer de carga para acomodar los picos aleatorios sin sobrecargar la infraestructura. Por ejemplo, si una carga normal del sistema es de 100,000 solicitudes por segundo, la infraestructura debe admitir 100,000 solicitudes en el 80% de la capacidad total (es decir, 125,000 solicitudes por segundo). Si prevé que la aplicación seguirá manteniendo 100,000 solicitudes por segundo y que la SKU actual (referencia de almacén) introduce una latencia a las 65,000 solicitudes por segundo, lo más probable es que necesite actualizar el producto a la siguiente SKU superior. Si hay una región secundaria, deberá asegurarse de que también admite la SKU superior.

• Pruebe la conmutación por error en varias regiones. Pruebe la cantidad de tiempo que se tardaría en volver a enrutar a los usuarios a la región emparejada para que no se produzca un error en la región. Normalmente, una conmutación por error de prueba planeada puede ayudar a determinar el tiempo que se necesitaría para escalar completamente para admitir la carga redirigida.

• Configure el entorno en función de los resultados de las pruebas para mantener la eficacia del rendimiento. Escale o reduzca horizontalmente para controlar los aumentos y las disminuciones de la carga. Por ejemplo, puede saber que encontrará altos niveles de tráfico durante el día y niveles bajos los fines de semana. Puede configurar el entorno para el escalado horizontal para los aumentos de la carga o para la reducción horizontal para las disminuciones antes de que la carga cambie realmente.

Herramientas de pruebas

• Elija las herramientas de prueba según el tipo de prueba de rendimiento que pretenda ejecutar. Hay varias herramientas de prueba de rendimiento disponibles para DevOps. Algunas, como JMeter, solo realizan pruebas con respecto a los puntos de conexión y los estados HTTP de las pruebas. Otras, como K6 y Selenium, pueden realizar pruebas que también comprueban la calidad y las variaciones de los datos. Application Insights, aunque no está diseñado necesariamente para probar la carga del servidor, puede probar el rendimiento de una aplicación en el explorador del usuario.

• Realización de pruebas de generación de perfiles de rendimiento y de carga durante el desarrollo, como parte de las rutinas de prueba y antes de la versión final para asegurarse de que la aplicación funciona y escala como corresponde. Estas pruebas deben realizarse en el mismo tipo de hardware que la plataforma de producción y con los mismos tipos y cantidades de datos y de carga de usuarios que se encontrarán en producción.

• Determine si es mejor utilizar pruebas manuales o automatizadas. Las pruebas pueden ser automatizadas o manuales. La automatización de las pruebas es la mejor manera de asegurarse de que se ejecuten. En función de la frecuencia con que se realicen las pruebas, se suelen limitar en duración y ámbito. Las pruebas manuales se ejecutan con mucha menos frecuencia.

• Almacene los datos en caché para mejorar el rendimiento, la escalabilidad y la disponibilidad. Cuantos más datos tenga, mayores serán las ventajas del almacenamiento en caché. El almacenamiento en caché funciona normalmente bien con datos inmutables o que cambian con poca frecuencia.

• Decida cómo va a controlar el desarrollo local y las pruebas cuando se prevea que una red de entrega de contenido (CDN) vaya a servir contenido estático . Por ejemplo, puede implementar previamente el contenido en la red CDN como parte del script de compilación. En su lugar, puede usar directivas o marcas de compilación para controlar cómo carga la aplicación los recursos. Por ejemplo, en modo de depuración, la aplicación puede cargar recursos estáticos desde una carpeta local. En modo de versión, la aplicación utilizaría la red CDN.

• Simule diferentes cargas de trabajo en la aplicación y mida el rendimiento de la aplicación de cada una. Esta técnica es la mejor forma de averiguar qué recursos deberá hospedar la aplicación. Use indicadores de rendimiento para evaluar si la aplicación funciona como se esperaba o no.

Recomendación

Defina una estrategia de pruebas. Para obtener más información, consulte Pruebas.

Pasos siguientes