Pruebas de rendimiento efectivas para su servidor con Autocannon

Rate this content
Bookmark

Experiencia en pruebas de rendimiento que se ha desarrollado durante mucho tiempo. Para medir el rendimiento de su servidor, necesita una herramienta que pueda simular eficientemente muchas habilidades y proporcionarle buenas mediciones según sus criterios de análisis.

La biblioteca NPM de Autocannon me dio exactamente eso: esa biblioteca es muy fácil de instalar y tiene una API muy simple con la que trabajar. En un corto período de tiempo, puede comenzar a realizar pruebas de rendimiento en su aplicación y obtener buenas mediciones en el entorno de desarrollo y en sus laboratorios de rendimiento, y generar escenarios de prueba complicados.

En esta charla presentaré Autocannon, explicaré cómo analizar eficientemente el rendimiento de su servidor con él y mostraré cómo me ayudó a entender problemas de rendimiento complicados en mis servidores Node.js. Al final de esta conferencia, los desarrolladores tendrán la capacidad de integrar una herramienta rápida y fácil para medir el rendimiento de su servidor.

Tamar Twena-Stern
Tamar Twena-Stern
36 min
19 Nov, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Tamar es un escritor de código experimentado y arquitecto con experiencia en Node.js. Las pruebas de rendimiento pueden ser confusas, pero entender términos como throughput y el percentil 99 es crucial. El percentil 99 es importante para hacer compromisos y garantizar la satisfacción del cliente. AutoCanon es una herramienta poderosa para simular solicitudes y analizar el rendimiento del servidor. Se puede instalar globalmente o utilizar como una biblioteca en Node.js. Autocannon es preferido sobre Gatling para las pruebas de rendimiento y se puede integrar con pruebas de extremo a extremo en Cypress.

Available in English

1. Introducción a Tamar y su experiencia

Short description:

Hola a todos. Soy Tamar, una apasionada escritora de código con amplia experiencia en la gestión de grupos de desarrollo y trabajando como arquitecta. Actualmente lidero el desarrollo de back-end en XM Cyber, una startup que simula la actividad de los hackers. Soy experta en Node.js y tengo un profundo entendimiento de su funcionamiento interno. Sígueme en Twitter para obtener más información y echa un vistazo a mis conferencias anteriores en YouTube. También soy una profesional del violín y líder de la comunidad en la comunidad JavaScript Israel. Únete a nuestras reuniones si estás en Israel.

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.

2. El Misterio de las Pruebas de Rendimiento

Short description:

Hablemos sobre el misterio de las pruebas de rendimiento. Puede ser confuso debido a la terminología y las mediciones desconocidas. Los conceptos clave incluyen el rendimiento, los usuarios concurrentes, el percentil 99 y el tiempo de respuesta promedio. Comprender estos términos es crucial para simular servidores y mejorar el rendimiento. El objetivo principal de las pruebas de rendimiento es determinar la capacidad de carga del servidor. Trabajar con un contenedor docker ayuda a medir el rendimiento, y duplicar los contenedores aumenta el número de solicitudes concurrentes. El percentil 99 del tiempo de respuesta y el rendimiento promedio son métricas esenciales a considerar.

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.

3. Importancia del Percentil 99

Short description:

En las pruebas de rendimiento, es crucial considerar el percentil 99. Esta métrica es importante porque proporciona una medida confiable del tiempo de respuesta. Al observar el percentil 99, podemos comprometernos con confianza con terceros, sabiendo que la gran mayoría de las solicitudes son más rápidas que un umbral específico. Esto garantiza un alto nivel de rendimiento y satisfacción del cliente.

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.

4. Entendiendo Solicitudes Concurrentes y AutoCanon

Short description:

La medición promedio de solicitudes concurrentes es crucial para entender el rendimiento del servidor. AutoCanon es una herramienta que simula solicitudes, permitiendo el envío simultáneo y control de usuarios concurrentes y tiempo de ejecución. Está escrita en Node.js y soporta canalización HTTP, HTTPS y conexiones concurrentes. La canalización HTTP envía múltiples solicitudes simultáneamente sin esperar respuestas, mientras que las conexiones concurrentes simulan usuarios acercándose a un sitio web. AutoCanon puede ser instalado y utilizado desde la línea de comandos.

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.

5. Instalación y Uso de AutoCANon

Short description:

Para instalar AutoCANon, usa NPM para instalarlo globalmente con menos-g. Esto te dará la herramienta de línea de comandos. Si quieres usar la API en tu código JavaScript, instálalo como cualquier otra biblioteca. Para Node.js, usa npm install AutoCANon menos menos save. Considera instalarlo con savedev para fines de desarrollo.

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.

6. Demo de Pruebas del Servidor con AutoCANon

Short description:

Echemos un vistazo a este código MyServer. Es un código de servidor escrito en Express, una biblioteca popular para alojar APIs HTTP. El código expone una ruta que cifra una contraseña utilizando un algoritmo intensivo y sincrónico de CPU. Probar el servidor con Autocannon proporcionará resultados para su evaluación.

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.

7. Pruebas de Rendimiento del Servidor y API Asincrónica

Short description:

El servidor está en funcionamiento en el puerto 3000. Se utiliza Autocannon para probar el rendimiento del servidor con los parámetros C, D y W. Se mide la latencia de la ejecución, siendo el percentil 99 de 1,5 segundos. El tiempo de respuesta promedio es de alrededor de 800 milisegundos, con una desviación estándar de 118 milisegundos. El servidor puede manejar un promedio de 12 solicitudes por segundo, con un máximo de 13. El segundo servidor, implementado en Express, utiliza una API asincrónica y no bloquea el bucle de eventos.

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.

8. Analizando el Rendimiento del Servidor con AutoCANON

Short description:

Después de ejecutar la versión asíncrona del servidor, el percentil 99 mejoró a 1.4 segundos y el tiempo de respuesta promedio se mantuvo alrededor de 700 milisegundos. El servidor ahora puede manejar un promedio de 14 solicitudes por segundo y hasta 20 solicitudes por segundo en carga máxima. AutoCANON es una herramienta poderosa para analizar el rendimiento del servidor y hacer mejoras.

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.

9. Simulando Solicitudes y Manejando Respuestas

Short description:

Puedes usar async await para crear una instancia y esperar a que termine de ejecutarse. Autocannon tiene una API de eventos de cliente, que te permite manejar respuestas específicas de la manera que quieras. Autocannon también proporciona la capacidad de enviar una variedad de solicitudes, como publicar un producto y luego publicar un catálogo utilizando el ID generado. Esto simula escenarios de la vida real.

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.

10. Consejos para Probar Escenarios de Producción

Short description:

Asegúrate de que los datos que estás probando sean similares a los que tienes en producción. Simula tus flujos de producción tanto como sea posible. Explora AutoCanon para escribir tus propias pruebas de rendimiento.

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.

QnA

Pruebas de Rendimiento y AutoCanon

Short description:

Muchas personas han realizado pruebas de rendimiento, y se está volviendo más importante a medida que avanzamos en línea. Las pruebas de estrés y carga son cruciales para entender la capacidad del servidor y asegurar que no colapsará bajo tráfico pico. AutoCanon proporciona flexibilidad en la escritura de escenarios de prueba y se prefiere sobre Gatling. Si tu computadora carece de potencia, considera orquestar un enjambre de computadoras para ejecutar AutoCanon.

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.

Despliegue en la Nube y Pruebas de Rendimiento

Short description:

Puedes desplegar el software que se está probando con Autocad en la nube. Es posible integrar Autocad con pruebas de extremo a extremo en Cypress. Es preferible realizar pruebas de rendimiento una vez al día en lugar de en cada CI, equilibrando la calidad y el tiempo invertido.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
Network Requests with Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Testing Pyramid Makes Little Sense, What We Can Use Instead
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
Gleb Bahmutov
Roman Sandler
2 authors
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
The Future of Performance Tooling
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
How to Start With Cypress
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
Filip Hric
Filip Hric
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Yevheniia Hlovatska
Yevheniia Hlovatska
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop