Pruebas de rendimiento efectivas para su servidor con Autocannon

Hola a todos. Estoy muy contenta de que hayan venido a mi sesión sobre performance testing con Autocanon. Pero primero, antes de que realmente vayamos y hagamos algunas cosas técnicas, me gustaría presentarme. Entonces, soy Tamar. He estado escribiendo code durante muchos años. Y es mi pasión escribir code. Además de eso, estuve gestionando grandes grupos de desarrollo y trabajé como arquitecta en varios lugares. Actualmente lidero el desarrollo de back-end en una startup llamada XM Cyber. Es una startup realmente genial. Lo que hacemos es imitar la actividad de un hacker en una red de computadoras. Además de eso, bueno, soy experta en Node.js. Y mi interés en Node.js comenzó cuando fundé mi propia startup y escribí todo mi back-end con Node.js. En ese momento realmente me enamoré de esa tecnología. Y comencé a investigarla y a entender sus partes más profundas. Y desde ese punto me he estado enfocando en esa tecnología. Y definitivamente es mi favorita. Puedes seguirme en Twitter y puedes encontrar conferencias anteriores mías en YouTube. Además de eso tengo tres hijos. También soy una violinista profesional. Y soy líder de la community en la community de JavaScript Israel. Organizamos líneas de encuentros realmente geniales. Así que si te encuentras por aquí y si te encuentras por aquí y en Israel y te encuentras con un encuentro de JavaScript Israel entonces es realmente agradable estar allí. Es recomendable.

Bien, ahora vamos a la parte técnica de la masterclass. Y me gustaría hablar un poco sobre el misterio de las performance testing. ¿Por qué lo llamo misterio? Porque digamos que la primera vez que hice performance testing sentí que estaba subiendo una montaña. Um, bueno, fue muy, muy difícil y confuso. ¿Por qué fue tan difícil y confuso? Porque tenía tantas preguntas porque todo el mundo hablaba mucho sobre una gran cantidad de terminología que no entendía.

Entonces, ¿a qué terminología me refiero? Bueno, cuando estás haciendo performance testing estás hablando de muchos términos y muchas mediciones con las que no estás familiarizado. Y al menos para mí, al principio, me dejó un poco confundido. Entonces, primero que nada el rendimiento. El rendimiento del servidor. ¿Cómo mides el rendimiento del servidor? ¿Qué significa eso? Quiero decir, puedo simular muchos escenarios de muchas maneras. Entonces, ¿cuál es la mejor manera de realmente, cuál es la mejor manera de medir el rendimiento del servidor? Además de eso, los usuarios concurrent. Entonces, bueno, los usuarios concurrent, ¿cómo afectaría eso a mi scale? ¿Qué es, quiero decir. ¿Qué son los usuarios concurrent? ¿Qué significa eso? ¿Qué es esa medición? ¿Cómo simular eso? ¿Cuál es la diferencia entre eso y entre el HTTP pipeline? Otra cosa que, ya sabes, es muy común cuando estás hablando de performance testing y hablando de benchmarking, es el percentil 99. ¿Qué es el percentil 99? ¿Por qué es muy importante? Porque a veces cuando mido y cuando la gente mide, estamos mirando el percentil 99 mucho más de lo que estamos mirando el promedio. Entonces, ¿por qué el percentil 99 es tan importante? Y lo último es el tiempo de respuesta promedio, o el tiempo de respuesta. Entonces, el tiempo de respuesta, cómo lo mides, si tienes que mirar el promedio o el percentil 99, también está la desviación estándar del benchmark que debe tenerse en cuenta. Entonces, todos esos cuando te encuentras con ellos por primera vez me dejaron muy confundido. Y tuve que entender exactamente lo que estaba haciendo para entender cómo simular mi servidor para que la prueba signifique algo y realmente mejore mi performance.

Entonces, expliquemos un poco sobre todos esos términos y solo un poco a un alto nivel para que te pongas al día con todo esto. Entonces, primero que nada, por supuesto, el objetivo principal para las performance testing es entender cuánta carga puede manejar nuestro servidor. Bueno, generalmente estás trabajando con un contenedor docker en mi opinión en performance testing y luego estás simulando solicitudes HTTP a ese único docker para entender qué rendimiento puede manejar este docker. Y si este contenedor puede manejar 100 solicitudes concurrent, cuando lo duplicas y creas otra instancia de él, creas otra réplica, entonces puedes manejar 200 solicitudes, etc. Si creas tres réplicas, entonces 300 solicitudes. Pero es realmente importante entender cuánta carga puede manejar un contenedor docker realmente. Entonces, pregunta importante que se necesitaba hacer. Entonces, ¿cuál es el percentil 99 de nuestro tiempo de respuesta? ¿Y cuál es el rendimiento? ¿Cuántas solicitudes concurrent podemos manejar en promedio? Quiero decir, esas son preguntas muy importantes. ¿Y por qué son importantes esas preguntas? Primero que nada, el percentil 99 del tiempo de respuesta.

Y en las pruebas de performance, es realmente importante mirar el percentil 99. Y la pregunta es por qué es importante hablar y mirar el percentil 99. ¿Por qué el percentil 99 es tan importante? Entonces, imagina que tienes un compromiso con un tercero, es decir, alguien está utilizando tu sistema y les estás diciendo, escucha, mis solicitudes siempre son más rápidas que digamos tres segundos. Si te basas en el promedio, entonces sabes, no es un data en el que puedas confiar. ¿Y por qué no es algo en lo que puedas confiar? Porque tienes desviación estándar. Por lo general, la mayoría de tus instancias no están alrededor del promedio. Puedes tener instancias que están lejos del promedio. Y en ese caso, en ese caso, es mejor mirar el percentil 99 porque eso significa que si son tres segundos, significa que el 99 por ciento de mis solicitudes fueron más rápidas que tres segundos y solo una solicitud, solo el 1% fue más lenta que tres segundos. Entonces sí, por eso. Y entonces estás muy seguro de dar un compromiso. Te sientes seguro con ese compromiso con un tercero para decir hey, sí, esto es algo, esto es algo en lo que puedo confiar. Mis solicitudes son más rápidas que tres segundos porque mi percentil 99 es de tres segundos. Por eso es importante esto.

Otra cosa, y esto es creo la medida más valiosa para entender el rendimiento de tu servidor es el promedio de solicitudes concurrent. ¿Cuál es la cantidad de solicitudes concurrent que pueden ejecutarse simultáneamente? Aquí estamos mirando el promedio y no en el percentil 99 porque en algunos casos o en la mayoría de los casos los percentiles 99 representan un pico porque cuando tienes un pico entonces tu servidor puede tener más. Y las solicitudes concurrent máximas son como tu rendimiento durante un pico. Pero esa es también una medida realmente importante.

Muy bien, así que después de hablar de todo eso hablemos de AutoCanon. Y cómo AutoCanon entra en la imagen. Entonces necesitas tener una herramienta que pueda simular solicitudes. Estoy hablando de enviar muchas solicitudes simultáneamente. Entonces necesitas algo que te ayude a enviar esas solicitudes simultáneamente. Necesitas controlar la cantidad de usuarios concurrent. Te gustaría controlar el tiempo de ejecución. Quiero decir que quieres que, como quieres que la herramienta se ejecute durante 15 minutos o 30 minutos durante un período de tiempo. Y así es como AutoCanon entra en la imagen como una herramienta realmente buena para simular, para simular performance testing y hacer benchmarking.

Entonces, ¿qué es AutoCanon? Entonces, AutoCanon es una herramienta para performance testing y una herramienta para benchmarking. Está escrita en Node.js, lo cual es realmente genial, así. Está escrita en el lenguaje. Y soporta canalización HTTP para HTTP. Soporta HTTPS. Soporta conexiones concurrent. Pero sí, estoy hablando de canalizaciones HTTP y estoy hablando de conexiones concurrent. ¿Y sabes qué? Hablemos de qué son las canalizaciones HTTP y qué son las conexiones concurrent y cuál es la diferencia entre ellas? Entonces, la canalización HTTP significa que estoy enviando... Bueno, el diagrama está en el lado izquierdo de esta pantalla. Canalización HTTP, significa que estoy enviando tres solicitudes y no tengo que esperar a que la primera regrese y luego enviar la segunda. Pero las estoy enviando simultáneamente. Las estoy enviando sin esperar la respuesta. Entonces, aquí en el lado izquierdo de la imagen, estoy enviando tres solicitudes sin esperar una respuesta. Luego, en el lado derecho, tenemos conexiones concurrent. Bueno, ¿qué significa eso? Significa que tenemos un socket abierto desde el cliente al servidor y tienes solicitudes en ese socket, pero eso es una simulación, una buena simulación de usuarios, por ejemplo, acercándose a tu sitio web porque si tienes como mil usuarios acercándose a tu sitio web, tienes miles de conexiones actuales. Eso es lo que puedo decir. ¿Cómo instalas el AutoCANon en sí? Primero que nada, si quieres instalarlo en la línea de comandos y usarlo desde la línea de comandos, a mí específicamente me gusta mucho usarlo desde la línea de comandos.

Puedes hacer NPM install AutoCANon y luego instalarlo globalmente con menos-g y luego tendrías la herramienta de línea de comandos de AutoCANon. Si quieres usar esta API desde tu JavaScript code, entonces puedes hacerlo, es como instalar una biblioteca para un proyecto JavaScript que escribes. Por ejemplo, para Node.js, normalmente haces menos menos save para que esa noción de biblioteca sea parte de tu paquete JSON. Así que definitivamente puedes hacer npm install AutoCANon menos menos save. Por cierto, en mi opinión, creo que necesitamos instalarlo con savedev y no con save, porque es una herramienta de desarrollo.

Pero ahora, después de hablar de ello, me gustaría mostrarles una interesante demostración sobre testing el servidor con AutoCANon. Y luego mostraremos la versión mejorada del servidor e intentaremos comparar algunos resultados.

Muy bien entonces. Genial, así que echemos un vistazo a este MyServer code. Vale, así que este es un servidor code que tenemos. Y espero que todos estén familiarizados con Express. Express es una biblioteca. Es una biblioteca extremadamente popular para alojar y publicar APIs HTTP para tus servidores. La sintaxis es realmente clara. Aquí estás requiriendo Express. Lo estás exponiendo en un puerto específico, en mi caso 3000. Aquí estás exponiendo una ruta. Esto se llama una ruta Express. Estoy exponiendo una ruta simple de get con una barra. Será un get HTTP. Lo que esta ruta está haciendo, bueno, tienes una función hash aquí. Esto está cifrando una contraseña. Le di como, una contraseña que es una constante aquí, contraseña aleatoria como puedes ver. Que, bueno, cuando entras aquí, tienes esta función. Estaba haciendo un algoritmo en criptografía. Está generando un hash a esta cadena que le transferí usando una sal, una sal aleatoria. Este algoritmo es lo que se llama intensivo de CPU, pero peor que eso, es sincrónico. Si estás mirando aquí, lo estoy usando en una API sincrónica de Node.js. No hay promesas de devolución de llamada ni nada de eso aquí, lo que significa que se ejecutará dentro del propio bucle de eventos. Y causaría como un congelamiento en mi code.

Así que intentemos probar un poco el servidor con Autocannon y probemos los resultados. Muy bien entonces. Así que esta es la línea de comandos. Y creo que la instancia del servidor está aquí. Bajémosla y pongámosla en marcha.

Así que aquí está en funcionamiento, el servidor está en el puerto 3000. Y luego hagamos Autocannon, ¿qué parámetros le doy? C, es el número de concurrent conexiones. D como puedes ver es la duración, y W son los trabajadores. Así que ahora no quiero darle trabajadores. Me gustaría que trabajara con C menos D. Presionemos enter.

Ahora contemos hasta 10. Uno, dos, tres, cuatro, cinco, seis, siete, ocho, genial, tenemos los resultados. Vale, veamos lo que tenemos aquí. Así que primero, veamos la latencia. Aquí está la latencia de esa ejecución, es decir, el tiempo de respuesta. Así que el percentil 99 es de 1.5 segundos. Lo que significa que el 99% de mis solicitudes fueron más rápidas que 1.5 segundos, y el 1% fue más lento que 1.5 segundos. Como puedes ver, el promedio estaba cerca de 800 milisegundos, y la desviación estándar es de 118 milisegundos. La solicitud máxima es de alrededor de 1.5 segundos. Así que estos son los data que tenemos aquí. Recordémoslo. 1.5 es el percentil 99. Vale.

Luego estamos viendo cuántas solicitudes por segundo. Así que podemos ver que, en promedio, estábamos manejando 12 solicitudes por segundo, pero como máximo estábamos manejando 13 solicitudes por segundo. Nunca manejamos menos de 10 solicitudes por segundo, así que como podemos ver, nuestro servidor, nuestro servidor NAS, puede manejar 10 solicitudes por segundo.

Ahora, después de hacer eso, detengamos el servidor y veamos el otro servidor que quería mostrarles. Bien, entonces, lo siento, vayamos a VS Code, no quería volver a mi presentación, pero, sí, puedes ver aquí, este es el segundo servidor. También está implementado en Express, un servidor Express simple. Muy simple y expone la misma API, pero aquí, estamos trabajando con la API asincrónica. Como puedes ver, está justo aquí. ¿Cómo sabes que es asincrónico? Aquí, hay una devolución de llamada que se está transfiriendo y resolviéndola, lo que significa que esto ya no es una operación sincrónica, sino asincrónica y se transfiere al bucle de eventos. Lo siento, se transfiere al worker fed y no bloquea mi bucle de eventos. Esto es lo que podemos decir sobre esa operación.

Entonces ahora, después de haber visto eso, vayamos a la línea de comandos y bueno, primero que nada, busquemos el servidor que teníamos. Lo siento por eso. Y como dijimos, este es el servidor. Ahora, estoy ejecutando la versión asíncrona del servidor que debería ser más eficiente. Y veamos los resultados ahora.

Bien, lo estamos ejecutando durante 10 segundos, ¿recuerdas? Uno, dos, tres, cuatro, cinco, seis, siete, ocho. Bien, veamos qué está pasando aquí. Primero que nada, el percentil 99 es de 1.4 segundos, que es mucho mejor que lo que tenemos en casi 100 milisegundos, así que es mejor. Lo siguiente es el promedio, que está cerca de 700 milisegundos. Y si recuerdas, el promedio anterior era alrededor de 700 milisegundos, lo cual es bueno. Y luego veamos cuántas respuestas podemos manejar. Entonces el promedio, si recuerdas, era alrededor de 12 solicitudes por segundo, por lo que el promedio subió a 14 solicitudes por segundo. Y el percentil 99 es de 20 solicitudes por segundo, lo que significa que en el pico podemos manejar 20 solicitudes simultáneamente, lo cual contrasta con la última ronda en la que el percentil 97 era de 14 solicitudes por segundo. Entonces sí, podemos ver que todas las mediciones han sido aprobadas, lo cual es bueno, pero esto es como una ejecución estándar de AutoCANON y así es como puedo ver el resultado y puedo analizarlos y este es un proceso de, bueno, aquí tenía un servidor y sabía cuál era el problema de antemano, pero puedes hacer este proceso y cambiar tu servidor y luego volver a ejecutarlo y ejecutar AutoCANON y mirar esas mediciones, como mediciones básicas, y ver si hay mejoras. Bien, genial.

Entonces ahora volvamos a nuestra presentación, a mi presentación, y continuemos con AutoCANON. Una cosa que me gustaría decir sobre AutoCANON, que es bastante genial, que es, bueno, AutoCANON en realidad utiliza hilos de trabajo. Espero que estés familiarizado con los hilos de trabajo. Es un modelo genial que se implementa en, comenzó en Node 10, ahora está implementado en, se ha vuelto no experimental en Node 12. Y nos permite ejecutar varios eventos en paralelo. Y bueno, este modelo es, bueno, se utiliza aquí en AutoCannon, lo cual es realmente genial. Entonces, si quieres trabajar con varios trabajadores, puedes hacerlo con una bandera de menos W. Bien, entonces comencemos a integrar AutoCannon con nuestro JavaScript code. Primero que nada, el ejemplo básico. Entonces mi objetivo principal es escribir testing herramientas, geniales testing herramientas que puedan ayudarme a probar mi aplicación. Entonces aquí hay un ejemplo básico donde obtenemos una instancia de AutoCannon y luego mira lo que estamos haciendo. Simplemente estamos comenzando la ejecución. Al final de la ejecución, lo estamos imprimiendo. Aquí tengo 10 concurrent conexiones. No quiero hacer HTTP pipelining, lo que significa que funciona de tal manera que envía una solicitud y espera una respuesta antes de enviar otra solicitud y la duración aquí es de 10 segundos.

Y así es como puedes simular. Otro ejemplo con async await, bueno, la mayoría de nosotros estamos trabajando con async await y como un moderno code de Node.js. Aquí async await, creando una instancia y estás esperando a que termine la ejecución y luego imprimes los resultados.

Otra cosa agradable que puedes hacer en tu code con autocannon es que tiene una API de eventos de cliente. Lo que significa que puedes recibir un evento y hacer algo con él. Por ejemplo, cada vez que recibes una respuesta específica puedes manejarla de la manera que quieras, lo cual puede ser útil. Así que esta es otra API que es realmente agradable de explorar.

Y lo último, usualmente cuando quieres hacer performance testing no quieres enviar la misma solicitud todo el tiempo. Te gustaría tener variedad de solicitudes. Aquí es donde la característica de Autocannon con solicitud, brújula, y entrando en acción. Aquí puedes ver en el ejemplo que tenemos dos solicitudes. La primera es una solicitud de post. Y lo que estamos haciendo aquí es que estamos publicando un producto y luego estamos obteniendo el ID en la respuesta que el servidor ha generado para nosotros. Y luego para ese producto, estamos publicando un catálogo en la segunda solicitud. Así que en la primera solicitud, este es el flujo, estamos publicando un ID. Lo siento, estamos publicando un producto, el servidor está generando un ID. Y luego en la segunda solicitud, podemos tomar el ID y publicar más data para él. Así que este es un flujo que puede darte variedad y flujo y múltiples solicitudes. Y esto está más cerca de simular escenarios de la vida real. Esto está más cerca de eso.

Muy bien, estamos muy cerca del final. Así que solo unos pequeños tips para testing escenarios de producción. En primer lugar, algo que al principio, no tenía en cuenta, y cuando me di cuenta, ha mejorado mucho mi performance testing. Tienes que asegurarte de que los data que estás testing sean similares a los que tienes en producción, es decir, si una colección tiene un tamaño específico, asegúrate de que tus datos simulados con los que estás probando también tengan el mismo tamaño, que los campos en producción sean idénticos a los campos que aparecen en tu database, que aparecen en tu database, y sí, y observa tus flujos de producción e intenta simularlos tanto como puedas. Eso fue todo, espero que mi masterclass te haya dado algunos conocimientos sobre performance testing y espero que explores un poco AutoCanon para intentar escribir tus propias pruebas de rendimiento para tus pruebas existentes. Así que eso era yo, ese es mi identificador de Twitter y muchas gracias por escuchar.

Muy bien, veo que muchas personas han realizado performance testing. Incluso como la mayoría de ustedes. Sí, creo que somos mayoría, un poco cerca, pero aún así estamos en un buen camino para hacerlo. ¿Qué esperas, estos resultados? En realidad, no. Pensé que como la mayoría de las personas no lo hacen, pero es bueno saber que como la mayoría de las personas se están profesionalizando en esta área. Es un tema difícil.

Oh, definitivamente. Y es muy importante, creo, especialmente que nos hemos movido en línea con tantos dispositivos y hemos tenido tantos problemas con el performance todo el tiempo, ¿verdad?

Sí, también hay muchos tipos de performance testing, hay pruebas de estrés, pruebas de carga, pruebas de pico. Sí, creo que es un buen punto que mencionaste, porque una de las preguntas que tenía era esta, ¿cuántos de estos tipos crees que podemos cubrir con una buena cantidad de trabajo, sin sacrificar y no publicar nada más, porque no está debidamente probado, o cuál sería el más importante de ellos para ser probado con seguridad? De los tipos que mencionaste.

Todos ellos deberían ser probados, quiero decir, y por cierto, en AutoCanon, puedes escribir scripts que pueden ayudarte a hacerlo de manera muy eficiente, como es muy importante hacer performance testing, pruebas de estrés, para entender cuánta carga puede manejar tu servidor. Y también es realmente importante entender, sabes, si tienes una cantidad específica de tráfico, y luego, de repente tienes un pico, es muy, muy importante asegurarte de que tu servidor no colapsará. Quiero decir, en los picos, hay muchos otros problemas como el autoescalado, tienes que ver que tomas otras instancias de tu servidor rápidamente y que tu usuario está obteniendo respuestas rápidas. Así que creo que si hablamos de priorización, por supuesto, las pruebas de estrés y carga son, al menos en mi opinión, las tareas con las que deberías empezar y luego deberías pasar a las pruebas de pico.

Sí, estoy de acuerdo, estoy de acuerdo. Ahora, sí, necesitamos un poco de priorización porque a veces simplemente no tenemos los recursos, por eso.

Bueno, entonces, Bamfa estaba preguntando, ¿cómo se compara AutoCAD con Gatling en cuanto a perfiles de inyección? Ejemplo, Ramp-up-Authors, lo siento, es un poco difícil para mí. Escenarios para aquellos que solicitan... Lo siento. ¿Puedes repetir cómo se compara AutoCAD con? Gatling, G-A-T-L-I-N-G. Y más como en cuanto a perfiles de inyección, escenarios o alimentadores.

Bueno, tengo que decir que normalmente no trabajo con Gatlings porque en realidad lo bueno de AutoCAD es que como desarrollador, puedo escribir lo que quiera, en cuanto a escenarios y todas las cosas que yo, sabes, bueno, la persona que hizo esta pregunta preguntó sobre cómo construir escenarios de testing. Así que me siento realmente cómodo haciéndolo en código. Y así me gusta más la flexibilidad de Autocad en cualquier escenario que quiera. Lo prefiero a adivinar.

Estoy de acuerdo. Para mí es más simple y da mejores resultados al menos para mí. Experiencia personal.

Sí, Mark tiene otra pregunta. Si mi computadora no tiene suficiente potencia para canalizar el servidor, ¿qué debería hacer? ¿Podría orquestar un enjambre de computadoras para ejecutar Autocad entonces? Estaba diciendo que su computadora no tiene suficiente potencia para ejecutar Autocad. Si entiendo correctamente.

Para canalizar el servidor. Sí, definitivamente, puede desplegarlo en la cloud y puede construir un clúster en la cloud y desplegar el software que está testing con Autocad allí. Oh, bueno saberlo. Bueno saberlo.

Tenemos otra pregunta de Mandalore QAM y la pregunta es, ¿puedes integrar Autocad con pruebas de extremo a extremo en Cypress? En servidores. Así que déjame entender correctamente. ¿En dónde? Cypress. Oh sí, lo siento. En realidad, no intenté integrarlo con Cypress, para ser honesto, pero si, puedes hacer integración de code en todas partes. No debería ser difícil. Sí, estoy de acuerdo. Y también, en este caso, hiciste una prueba, tal vez nos pueden informar después.

Y tal vez una última pregunta, creo que tenemos tiempo. ¿Estás integrándolo en un CI o ejecutando pruebas de performance de manera continua, como una vez al día o en cada despliegue? Bueno, personalmente apoyo el enfoque de ejecutar pruebas de performance una vez al día, digamos, y no en cada CI, porque es, creo que ralentiza un poco el desarrollo. Por supuesto, tiene la desventaja de, ya sabes, no saber en qué commit específico se rompieron las cosas. Pero creo que el desarrollo más rápido sucede cuando se ejecutan una vez al día. Oh, esa es una opinión interesante. Porque estos días, todo se empuja a ser como DevOps, KOps, todo se integra en el pipeline continuo. Y tal vez deberíamos simplemente- La cosa es que esta tarea es larga. Y, ya sabes, al menos como en X y cyber, tenemos un enorme CICD, que hace muchas cosas. Y en realidad es muy eficiente y encuentra muchos bugs. Pero esta tarea específica es larga. Sí, así que significaría que un desarrollador tendría que esperar unas pocas horas. Como que añade unas pocas horas a todo. Es largo. Sí, definitivamente. Y tienes que equilibrar la calidad y el tiempo invertido. Muchas gracias Tamara por unirte a nosotros. Genial. Muchas gracias por estar aquí. Y gracias por la gran charla. Fue agradable tenerte por aquí. Muchas gracias.