Si estás intentando hacer pruebas de performance con sistemas que utilizan la librería Socket.IO, una de las mejores maneras de hacerlo es usando Locust, Taurus y BlazeMeter. Para profundizar en este tema, te invitamos a leer este artículo de December Labs, uno de nuestros sponsors en Quality Sense Conf.
Por December Labs
Sabemos que JMeter es la herramienta más potente que se utiliza hoy en día. Es la primera que se nos viene a la mente cuando pensamos en hacer pruebas de performance, pero lo que puede ocurrir es que nos haga perder tiempo, dinero y recursos.
Desde December Labs, nos propusimos escribir este artículo para ofrecerte mejores opciones para esta situación concreta. Por eso, sin más preámbulos, vamos a contarte nuestra experiencia:
Actualmente, las aplicaciones de chat son una de las principales herramientas de comunicación. Simples de usar y muy efectivas, están siendo aprovechadas por una gran diversidad de personas, de diferentes edades. Por ello, es crucial encontrar la mejor herramienta de pruebas de performance que garantice su permanencia, y una buena experiencia del usuario.
Las aplicaciones en tiempo real (RTA) son cada vez más populares en nuestro campo. Funcionan en un periodo de tiempo que aporta la idea de comunicación instantánea, por lo cual los usuarios no necesitan actualizar la app/sitio web para recibir nuevos mensajes. Algunos ejemplos famosos de este tipo de aplicaciones son los chats instantáneos, como WhatsApp, Telegram y Facebook Messenger.
La librería Sockei.IO se ha hecho muy popular en la implementación de este tipo de aplicaciones, porque ayuda a mejorar la experiencia del usuario. Grandes organizaciones como Microsoft Office, Yammer, Zendesk y Trello, entre otras, se centran en el uso de esta biblioteca JavaScript para crear sistemas sólidos en tiempo real.
La popularidad de Socket.IO presenta importantes desafíos para los testers de software, en la creación de pruebas de referencia robustas para este tipo de sistemas. Por eso, a través de este artículo, vamos a compartir lo que experimentamos en el desarrollo de este tipo de pruebas.
En la experiencia en que vamos a hacer foco, nuestro objetivo inicial era desarrollar una aplicación que pudiera soportar 10 mil usuarios concurrentes, cuyos tiempos de respuesta estuvieran dentro de un rango aceptable. Además, encontrar cuellos de botella, en el caso de que existieran.
Primera ronda: JMeter
Comenzamos las pruebas de performance utilizando JMeter como herramienta principal porque tiene buena reputación y una comunidad muy grande de usuarios, además de mucha documentación. Sin embargo, inmediatamente empezamos a enfrentarnos a diferentes limitaciones:
❌La comunicación cliente-servidor no se restablecía.
❌La interacción con el servidor de respuesta era compleja.
❌Había problemas con las escalas de prueba.
❌Los plugins no funcionaban como esperábamos.
Después de un tiempo, nos dimos cuenta de que había mejores soluciones que JMeter. En ese momento, comenzamos con el proceso de investigación, y buscamos nuevas tecnologías para lograr nuestros objetivos. Finalmente, encontramos algunas herramientas nuevas que nos permitieron desarrollar nuestro script de pruebas para probar la aplicación Socket.IO.
Segunda ronda: Locust + Taurus + BlazeMeter
Descubrimos Locust, una herramienta de línea de comandos escrita en Python. Con ella, las pruebas de carga son distribuibles y escalables, lo cual permite poner en marcha rápidamente una prueba que simula miles de usuarios.
Locust tiene la ventaja de no requerir grandes archivos de configuración. De este modo, probar la aplicación basada en Socket.IO es más fácil que con JMeter. Para los testers que prefieren una interfaz de línea de comandos, se trata de una herramienta más rápida y fácil de configurar. Esto permite reutilizar fácilmente el código de prueba entre proyectos. El lenguaje para crear la prueba es Python, que se puede almacenar en el sistema de control de versiones junto con el proyecto, y facilita volver a ejecutar las mismas pruebas en el futuro.
El primer paso para crear nuestra prueba con Locust fue desarrollar un cliente Socket.IO que pudiera simular los flujos de nuestros usuarios finales y aportar valor a nuestras pruebas de performance. Como el objetivo final de nuestra prueba era soportar un elevado número de usuarios concurrentes, utilizamos BlazeMeter, para aprovechar su infraestructura y ejecutar nuestras pruebas en la nube.
BlazeMeter es una herramienta de pruebas de performance muy popular basada en SaaS, totalmente compatible con muchas pruebas de carga de código abierto. Decidimos utilizar BlazeMeter por las ventajas que ofrece, entre las cuales destacamos:
✔️Una forma sencilla de mantener y ejecutar los scripts desde una única ubicación.
✔️La capacidad de generar hasta 1 millón de usuarios virtuales, sin necesidad de preocuparse por el coste y la configuración de la infraestructura.
✔️Supervisión e informes en tiempo real.
✔️Fácil acceso a informes históricos.
Para poder ejecutar nuestras pruebas en BlazeMeter, tuvimos que personalizar la imagen. Para ello, añadimos la biblioteca Socket.IO al finalizar la ejecución de BlazeMeter.
Si te encuentras en la misma situación, puede que te preguntes si es posible generar informes de BlazeMeter u obtener tiempos de respuesta gráficos. Es posible que la respuesta sea negativa, o al menos lo era hace seis meses. Por este motivo, decidimos crear la última versión de nuestras pruebas sin BlazeMeter, utilizando ahora únicamente Locust y Taurus.
Test Automation Running Smoothly (Taurus) es una herramienta de automatización gratuita y abierta creada por BlazeMeter. Proporciona una capa de abstracción sobre los scripts de prueba. Así, ofrece una forma amigable de desarrollar y configurar nuestro script.
La idea inicial con Taurus era utilizarlo como un mapeador entre el script Locust y la infraestructura de BlazeMeter, ya que al hacerlo parecía que sería fácil construir la integración a través de sus lenguajes (JSON o YML).
Algunas ventajas de Taurus:
✔️Fácil instalación y configuración.
✔️Las pruebas se escriben utilizando JSON o YAML.
✔️Posibilidad de ejecutar scripts de prueba existentes.
✔️Combinación sencilla de varios guiones de prueba en una sola ejecución de prueba.
✔️Informes en tiempo real.
✔️Integración con el panel de informes BlazeMeter.
Dado que nuestra idea inicial era probar la aplicación ejecutando 10 mil usuarios concurrentes, pero ahora lo haríamos sin BlazeMeter y utilizando únicamente Locust y Taurus, nos aseguramos de tener un ordenador con muchos recursos disponibles. También hicimos un docker-compose, con las configuraciones necesarias para hacer posible la ejecución de los scripts de Locust y Taurus. De este modo, posibilitamos su ejecución en paralelo, o en diferentes ordenadores, por si fuera necesario simular más usuarios virtuales.
Conclusión
Pudimos realizar una prueba a la cantidad de usuarios virtuales deseados. También logramos nuestros objetivos trabajando conjuntamente con el equipo de desarrollo. Fue posible solucionar los problemas en nuestro proceso de pruebas de modo continuo, siempre con foco en nuestros objetivos: un buen tiempo de respuesta, la eliminación de cualquier posible cuello de botella y, lo más importante, el soporte de 10 mil usuarios virtuales concurrentes.
Estudiar las herramientas disponibles antes de comenzar cada prueba es algo que será siempre necesario, para asegurarnos de que disponemos de los medios adecuados para lograr el propósito final. Se puede lograr los mejores resultados mediante el análisis y la elección de las herramientas correctas para crear pruebas robustas, escalables y fiables.
Si estás a punto de empezar a realizar pruebas de performance con Socket.IO, esperamos que este artículo te ayude en tu camino.
Etiquetas
Posts Relacionados
Accesibilidad web para diseñadores
¿Sabía que la accesibilidad web es un requerimiento base para cualquier proyecto digital? Conozca los principios para un diseño de interfaz de usuario accesible.
Plan de pruebas de performance: Incrementa la confiabilidad y seguridad de tus sistemas
Conoce los diferentes tipos de tests de rendimiento y las consideraciones clave para diseñar un plan de pruebas de performance, antes de decidir cómo simular la carga.