Tipos de pruebas de carga

Los siguientes tipos de pruebas se basan en las preguntas fundamentales enumeradas anteriormente en la guía.

¿Cuánta carga puede soportar mi aplicación?

Al configurar una prueba para determinar la carga que puede soportar la aplicación, primero decida si quiere medirla en solicitudes por segundo (solicitudes/s), tiempo de respuesta (segundos) o en usuarios simultáneos. En cualquier caso, defina qué parte de la aplicación se va a probar.

• Navegar por el sitio es una carga que se consigue visitando varias páginas o puntos de conexión, o solicitando datos desde un único punto de conexión mediante diferentes parámetros para cada solicitud. A menudo, esto se consigue utilizando las herramientas básicas que se describen en la sección Herramientas a utilizar. Debido a que la caché suele ser un componente vital de una aplicación, decida si desea incluir una capa de almacenamiento en caché en la prueba.

• Probar los flujos de trabajo transaccionales, como un proceso de pago en los que las solicitudes dependen unas de otras y se transfieren los datos entre las solicitudes, requieren herramientas más complejas. Además, debido a que la medición de las solicitudes tiene una relevancia limitada en el contexto de una transacción de varios pasos, es más preciso contar toda la transacción, que la herramienta debe emitir como un punto de datos independiente. Las herramientas Apache JMeter y k6 se pueden configurar para proporcionar estos puntos de datos.

Defina el umbral aceptable para el rendimiento y la tasa de errores del sistema de destino. En algunos sistemas, es posible que no le interesen los tiempos de respuesta, siempre y cuando el evento se procese correctamente. Para muchas aplicaciones, como las que requieren la interacción del usuario, defina los límites de lo que es aceptable para el usuario final.

Suele ser útil realizar las pruebas por etapas. La carga aumenta con cada paso hasta alcanzar el umbral definido. En el caso de las pruebas repetidas, puede aprender de las pruebas anteriores y mejorar sus pasos para realizar menos pasos en una prueba y, aun así, obtener resultados válidos.

¿Puede mi aplicación soportar una carga X?

Al igual que en la prueba anterior, la carga de esta prueba se puede definir como solicitudes por segundo o como usuarios simultáneos, según la naturaleza de la aplicación que se esté probando. Esta prueba es una versión simplificada de la anterior. En este caso, se debe enviar una carga de trabajo específica y el sistema debe poder manejarla. Es importante elegir una herramienta de prueba que permita especificar el volumen de carga que necesita.

El tiempo de ejecución de la prueba también puede ser relevante. Algunos efectos solo se pueden observar cuando la prueba se realiza durante un periodo más prolongado. Por ejemplo, la contrapresión puede provocar que las colas se sobrecarguen. Si desea replicar un sistema de producción y sacar conclusiones válidas, el tiempo necesario para ejecutar la prueba puede afectar al tamaño del sistema de prueba.

¿Mi aplicación se puede reducir y escalar verticalmente de forma automática?

La elasticidad es un punto de venta clave de la nube y una fuente clave de reducción de costos. Probar si su aplicación se está escalando correctamente, de modo que pueda beneficiarse con confianza de la elasticidad, debería ser parte de su traspaso a la nube.

Es necesario identificar las métricas clave que se utilizan para reducir y escalar verticalmente. Normalmente, se trata de la carga de CPU de los sistemas de destino. Un punto de conexión que genera una carga de CPU se puede utilizar como destino.

Como esta prueba no requiere capacidad de representación, puede ser beneficioso centrarse en un punto de conexión que no presente efectos secundarios. Tampoco es recomendable iniciar un flujo que persista en los datos que podrían acumularse o que inicie procesos posteriores e genere costos innecesarios o bloquee la carga.

Realice la prueba en un proceso escalonado, aumentando gradualmente la carga. Los intervalos deben ser lo suficientemente largos como para que, en cada paso, las métricas puedan iniciar el escalado. Por ejemplo, si por regla general la carga de la CPU debe ser superior al 70 por ciento durante un periodo de 5 minutos, las etapas deben durar más de 5 minutos para dar tiempo a que se inicie y ejecute el evento de escalado. También querrá comprobar que el escalado funciona y que ha solucionado la situación de carga que ha creado.

Considere iniciar la prueba de escalado con más de un servidor. En un entorno pequeño, el escalado puede ser lento y requerir varios ciclos para soportar la carga. Y un clúster EC2 de Auto Scaling solo puede duplicar su tamaño. Esto significa que si comienza con un servidor e inicia la prueba de carga, el primer evento de escalado máximo solo puede ser de dos servidores. Si la carga generada requiere tres servidores, necesitaría dos eventos de escalado, lo que podría tardar 20 minutos o más.

Monitoree el desencadenante deseado para el evento de escalado verticalmente y si el escalado fue apropiado para la carga real.

Si ha implementado un evento de reducción vertical, también puede probarlo de forma escalonada. Monitoree si la reducción vertical es aplicable y adecuada para la carga existente y confirme que no vuelve a iniciar un escalado vertical inmediato.

¿El comportamiento de mi aplicación empeora con el tiempo con una carga alta constante?

Algunos efectos solo se pueden observar cuando la carga se genera durante un periodo prolongado. Uno de los efectos más importantes es la contrapresión. Esto significa que cuando un sistema es demasiado lento para procesar el número de solicitudes a la velocidad a la que llegan, el rendimiento de sus sistemas cliente empeorará.

Esto es más fácil de observar si el objetivo de carga es el sistema lento. En una configuración más compleja, solo se puede observar el efecto cuando el impacto de la prueba de carga se propaga. Una solución de seguimiento que pueda visualizar los tiempos de respuesta entre cada uno de los servicios de un sistema distribuido no solo muestra los resultados con mayor rapidez, sino que también puede ayudar a identificar el sistema que actúa como un cuello de botella. Para identificar el cuello de botella del sistema, obtenga el identificador de correlación de mensajes de los archivos de registro. Cada solicitud conserva el mismo ID en todos los sistemas que se someten a la prueba de carga.

El uso de un identificador de correlación lo ayuda a realizar un seguimiento de todo el recorrido de un solo mensaje a través de los distintos componentes de su plataforma. Con esta información, puede calcular el tiempo de procesamiento de cada uno de los componentes que atraviesa el mensaje (processing_time = departure_time — arrival_time) e identificar el más lento. Zipkin, Jaeger yAWS X-Ray son soluciones destacadas en este espacio.

Para obtener los resultados más fiables, elija una herramienta que permita establecer una tasa de solicitudes constante. Esto significa que si el sistema de destino es cada vez más lento, la simultaneidad de la herramienta de prueba debe aumentar o mantener la velocidadreq/s constant. When the system starts to respond more slowly, it will tie up more threads and lower the request rate of your load-generating tool. A tool with a constant request rate must increase concurrency when happens, and you will see failure faster. Instead of measuring degradation by achieved req/s, se medirá por la latencia e incluso por las solicitudes fallidas.

¿Funciona mi aplicación?

Por lo general, no se crearía una carga elevada, sino un número razonable de solicitudes para verificar la funcionalidad. También puede hacerlo periódicamente en el entorno de producción, cuando los clientes no visiten los flujos probados, para disponer de otro nivel de monitoreo.

Como método abreviado, los escenarios ya creados para las pruebas de carga se pueden reutilizar en producción con una carga inferior configurada.