Los 10 mandamientos para probar eficazmente los límites de su plataforma web
1. Objetivos
Las pruebas de carga suelen verse como una forma de determinar si una plataforma puede soportar 500, 1.000 o 10.000 usuarios simultáneos. En realidad no es así. Para probar este tipo de afirmación, los escenarios utilizados durante las pruebas de carga tendrían que coincidir con el comportamiento exacto de los usuarios reales que fluyen hacia la plataforma y utilizan el servicio, lo cual es realísticamente imposible de conseguir.
Las pruebas de carga deben considerarse más bien como una herramienta que pone de relieve los SPOF (Single Point Of Failure), los puntos débiles, los cuellos de botella y los puntos de ruptura de la plataforma para saber dónde debemos centrar nuestros esfuerzos con el fin de mejorar la eficiencia y la resistencia de la infraestructura o del código de la aplicación.
Estas pruebas también son útiles para medir la evolución del rendimiento de la plataforma a medida que se actualiza la infraestructura o la aplicación.
Por último, combinadas con un sistema de metrología, estas pruebas pueden utilizarse para definir eficazmente los umbrales de alerta que deben establecerse para anticiparse a las degradaciones del rendimiento, o para encontrar los indicadores y umbrales que deben vigilarse al establecer infraestructuras dinámicas con mecanismos como el autoescalado.
2. Herramientas
Hay una buena cantidad de herramientas disponibles para realizar pruebas de estrés y pruebas de carga.
En Iguana Solutions, tenemos una gran experiencia utilizando Gatling y Octoperf(JMeter). Ninguna herramienta es mejor que la otra y todas tienen sus pros y sus contras.
Preferimos herramientas con características adaptadas a nuestras necesidades(fácil creación de escenarios mediante el uso de proxies, creación de informes estandarizados y fácilmente interpretables, personalización y configuración avanzadas, fácil integración en la aplicación), que nos permitan aplicar un plan de pruebas definido de antemano.
Una metodología rigurosa también nos permite poder reutilizar el conjunto para leer, comparar y comprender los resultados y hacer síntesis comprensibles para todos.
3. Escenario (más pragmatismo que perfección)
Como se mencionó en la sección de objetivos, es casi imposible desarrollar el escenario perfecto que va a predecir y replicar el comportamiento real de sus clientes y / o usuarios.
Por eso recomendamos desarrollar múltiples escenarios (entre 3 y 5 dependiendo de la complejidad y profundidad de su servicio o aplicación) que describan lo mejor posible el supuesto comportamiento de los usuarios. A continuación, esos escenarios pueden someterse a pruebas más o menos intensas en función de su probabilidad.
En Iguana Solutions, trabajamos con muchos comerciantes en línea. Solemos aconsejarles que creen al menos 3 escenarios básicos:
- La primera simula que un usuario no autenticado navega por el sitio web, de modo que podemos probar las distintas capas de caché;
- Otro escenario en el que el usuario se conecta, navega por los artículos, añade algunos productos a su cesta y finaliza el pedido;
- Y, por último, un escenario en el que un usuario simplemente crea una cuenta.
Para todos los demás sectores o casos de uso, y como nota general, utilizamos nuestra experiencia para definir con nuestros clientes una lista de páginas, funciones y transacciones que consumen muchos recursos de la plataforma (cálculo, memoria, almacenamiento) con el fin de integrarlas en los escenarios.
4. Utilizar datos dinámicos (pensar en el tiempo y en los datos)
El tiempo de reflexión es el tiempo medio que un usuario está navegando por una página web y pensando antes de realizar la siguiente acción. Del lado de la plataforma, se materializa por una pausa de duración variable entre las diferentes peticiones que llegan. Es esencial implementar este parámetro en tus pruebas para que tu escenario sea realista y no demasiado agresivo con tu plataforma. Por supuesto, recomendamos aleatorizar el tiempo de reflexión utilizando un intervalo de tiempo razonable.
La mayoría de las herramientas ofrecen esta función por defecto, pero el reto consiste en encontrar un valor realista para el tiempo de reflexión en función de su audiencia específica. Para ello, puedes recurrir a tus herramientas habituales de analítica web, como Google Analytics, Fathom Analytics, Matomo... para comprobar cuánto tiempo permanecen tus usuarios reales en una página de tu sitio antes de actuar en ella.
Por último, puede ser útil introducir en sus pruebas algunos datos dinámicos (envío de un formulario, un fichero, un conjunto de datos) para anticipar estos comportamientos que a menudo consumen muchos recursos de la plataforma.
5. Reutilización (pruebas frecuentes, CI/CD)
Uno de los principales objetivos de las pruebas de carga es saber si un commit en tu código o infraestructura conlleva alguna pérdida de rendimiento. Por eso es esencial incluir pruebas de carga en tu proceso de desarrollo ágil.
Por ejemplo, después de cada push en el entorno de preparación, puede activar una prueba de carga y comparar el resultado con el push anterior para emitir una advertencia si el rendimiento no es tan bueno como antes. Toda esta cadena de eventos puede automatizarse por completo en su proceso CI/CD.
Es esencial realizar pruebas a menudo y por eso también le recomendamos que empiece a desarrollar sus escenarios al principio del ciclo de vida de su aplicación.
6. Metrología
La metrología es esencial a la hora de analizar los resultados de sus pruebas. Te permite determinar rápidamente dónde están los cuellos de botella de tu plataforma ofreciéndote métricas detalladas de cada servicio y parte de tu infraestructura.
Aquí en Iguana Solutions cuando realizamos pruebas de carga nos aseguramos de medir las métricas de hardware tales como el uso de CPU, RAM, Disco y Red de cada componente de la infraestructura.
Pero también muchas métricas de middleware para servicios como Nginx, Apache, Varnish, HAproxy, Redis, MySQL...
Además de estas métricas, recomendamos encarecidamente utilizar RUM (Real User Monitoring) y herramientas de perfilado de aplicaciones como NewRelic, AppDynamics, Data Dog...
El objetivo, obviamente, es tener una visión completa de lo que está ocurriendo en el hardware, el middleware y el software para entender dónde hay que centrar los esfuerzos para poder escalar la plataforma de forma más eficiente.
Herramientas como Newrelic son muy buenas para determinar dónde pasa la aplicación la mayor parte del tiempo. Según nuestra experiencia, observar el tiempo empleado durante las peticiones a la base de datos es siempre un buen comienzo para investigar y mejorar el rendimiento.
7. Puesta en escena/Producción
En Iguana Solutions siempre recomendamos y configuramos infraestructuras similares para producción y staging, normalmente con capacidades de computación menores y redundancia algo reducida para este último entorno.
El objetivo principal aquí es garantizar que la aplicación se comporta de la misma manera en staging que en producción, utilizando los mismos mecanismos de equilibrio de carga, mecanismos de almacenamiento en caché, etc.
Sin embargo, aunque recomendamos encarecidamente probar todas las implantaciones en el entorno de ensayo, también aconsejamos programar al menos una prueba de carga semanal en la plataforma de producción, quizá por la noche o durante un periodo de actividad tranquila.
8. Pruebas de estrés frente a pruebas de carga
Creemos que podría ser relevante mencionar que en realidad hay 2 tipos de pruebas que se pueden realizar: Pruebas de Estrés y Pruebas de Carga.
Ambos tienen objetivos y consecuencias diferentes:
- Prueba de resistencia
El objetivo de una prueba de estrés suele ser llevar la plataforma a sus límites absolutos, con el fin de detectar puntos de ruptura claros. Como el objetivo de una prueba de estrés es saturar completamente la plataforma, no recomendamos realizarlas en un entorno de producción. En su lugar, si desea tener una idea clara de los límites de su entorno de producción, le aconsejamos escalar temporalmente su entorno de ensayo para que coincida con su capacidad de producción.
- Pruebas de carga
Las pruebas de carga suelen ser menos exigentes con la plataforma. El objetivo aquí es inyectar una cantidad razonable de escenarios para observar cómo reaccionan la plataforma y la aplicación para garantizar que la última confirmación de código o el último cambio en la infraestructura no han afectado negativamente al rendimiento o la escalabilidad.
9. Pensar con originalidad
Normalmente se recomienda realizar las cargas o pruebas de estrés desde una infraestructura externa. Por ejemplo, en Iguana Solutions siempre lanzamos nuestras pruebas desde un entorno aislado de AWS o GCP, independientemente de dónde esté alojada la plataforma que queramos probar.
De este modo, podrá probar la capacidad de toda su stack (incluida su capacidad para gestionar el tráfico entrante procedente de otra red) en lugar de trabajar desde su red local.
10. Yendo más lejos
Mediante el uso de pruebas de carga vimos cómo podíamos identificar SPOFs (Single Point Of Failure), debilidades, cuellos de botella y puntos de ruptura de una plataforma. Pero cuando inicias el proceso de mejora continua de tu plataforma, también es importante pensar en la parte del rendimiento web en el frontend.
En efecto, los motores de búsqueda como google, yahoo y bing promueven naturalmente los sitios web que respetan y contienen algunas características y métodos de rendimiento. Esto es lo que llamamos SEO (Search Engine Optimization) y algunas de las ganancias rápidas son optimizar el tamaño de su estática, comprimir utilizando Gzip o brotli cuando sea posible, utilizar HTTP2, ejecutar Javascript no importante al final de la página de carga, utilizar los últimos cifrados SSL etc..
Disponemos de varias herramientas que nos permiten analizar, controlar y tomar medidas en consecuencia. Por ejemplousamos en Iguana Solutions GTmetrix o Test de páginas web.
Estas herramientas nos permiten tener una evaluación completa del webperf de nuestra página web y nos dan indicaciones sobre los puntos a mejorar como la tasa de retención de caché, el tamaño de las imágenes o el orden en el que debemos cargar algunos scripts JS.
Póngase en contacto con Iguana Solutions para obtener más información y cuéntenos sus necesidades.
