Pruebas de Rendimiento, ¿qué pasa si en vez de 1 usuario, tengo 1.000?

Siempre que explico el porqué de las pruebas de rendimiento, creo que es muy útil explicar el contexto en el que surgen:

Hoy día y cada vez con mayor frecuencia, tendemos a virtualizar actividades cotidianas de nuestra vida, como puede ser la comunicación, tanto a nivel profesional o personal, gestionar compras, inversiones, etc. ¿Quién quiere hacer largas colas para conseguir las entradas del concierto del año, cuando puedes gestionar la compra en 5 minutos desde el sofá de tu casa?

Esto realmente nos abre un gran abanico de posibilidades, pero también nos hace cada vez más exigente con la calidad y estabilidad de las aplicaciones que utilizamos. De hecho, una de las grandes preocupaciones de las empresas cuando abren sus aplicaciones al público, es que éstos valoren positivamente su experiencia, ya que un comportamiento anómalo puede llegar a frustrar la captación y continuidad de los usuarios y/o clientes.

¿Cómo podemos asegurar que nuestros usuarios tienen una buena experiencia con la aplicación sin importar la afluencia o nivel de concurrencia en ella?

«No tengo una bola de cristal«, me han dicho algunos compañeros cuando me he quejado del bajo rendimiento de algunos portales online. Y es que, lamentablemente, una falta de validación en el ámbito de rendimiento, puede llevar a que grandes campañas como rebajas, estrenos u otros eventos generen un impacto negativo y por tanto contraproducente en nuestra imagen de marca, en lugar de generar confianza y en definitiva una correcta experiencia de usuario.

Pues no, no tenemos esta bola de cristal, pero tenemos las pruebas de rendimiento, que nos permiten reproducir distintos escenarios de carga en el que se simule la actividad de usuarios reales. Así, podremos evaluar cómo se comporta la arquitectura que soporta una determinada plataforma bajo carga, antes de que ésta ocurran en realidad y por tanto, resolver problemas potenciales antes de que éstos mismos sean identificados en Producción.

Como podeis imaginar, estos escenarios que reproducimos se han de diseñar prediciendo una determinada afluencia de usuarios. En pruebas de rendimiento, la planificación y el control de la carga son claves para poder asegurar que obtenemos unas conclusiones consistentes; dicho de otra manera, debo:

• Identificar al público objetivo al que va dirigida, estimar los tiempos de respuesta que se consideran aceptables y conocer cómo acceden los usuarios.
• Evaluar las previsiones de negocio, normalmente a corto y medio plazos.
• Cuantificar la máxima cantidad de carga que debo generar.
• Dimensionar y analizar en detalle cada componente de la infraestructura que soporta mi aplicación. 

Estas previsiones nos dan las condiciones para diseñar lo que llamamos ‘Escenario de Carga’, donde reproduciremos un perfil realista y nos permitirá analizar cómo se comporta la plataforma en estos casos. Una vez (y sólo una vez) hayamos confirmado la estabilidad del sistema en el escenario realista, lo llevaremos más allá con la carga, hacia un ‘Escenario de Stress’, con el que podremos identificar y aislar los puntos débiles o cuellos de botella.

Y, tras las ejecuciones, queda la parte que yo considero más apasionante. Hemos recopilado, cientos, miles de datos y tenemos que analizarlos. Necesitamos evaluar cómo evolucionan los tiempos de respuesta y la carga generada mientras la cantidad de usuarios crece. Si has diseñado y ejecutado correctamente estas pruebas, ¡enhorabuena! Sabes en qué puntos los tiempos de respuesta se disparan hasta ser inasumibles o bien comenzamos a recibir errores y lo más importante, sabes si necesitas aplicar algún correctivo antes de poner tu aplicación en Producción.

En este punto, espero haber transmitido la necesidad de una buena definición, planificación y ejecución de las pruebas de rendimiento pero permitidme una última observación: debemos asegurar detección temprana de fallos, pero antes de planificar cualquier tipo de escenario de rendimiento, tenemos que asegurar que los escenarios a reproducir sean estables. Dicho de otra manera, primero debemos asegurar que la aplicación funciona para 1 usuario y después…  ¿qué pasa si en vez de 1 usuario, tengo 1.000?