Pruebas de rendimiento efectivas para su servidor con Autocannon

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

Autocannon es una herramienta para realizar pruebas de rendimiento y benchmarking, escrita en Node.js. Se utiliza para simular solicitudes HTTP a un servidor para analizar cómo maneja diferentes cargas, lo que permite identificar y mejorar el rendimiento del servidor.

Los usuarios concurrentes se refieren a las solicitudes simultáneas que un servidor recibe y maneja en un momento dado. El número de usuarios concurrentes puede impactar significativamente en el rendimiento del servidor, determinando cuántas solicitudes puede procesar simultáneamente sin degradar la calidad del servicio.

El percentil 99 es una métrica crítica en las pruebas de rendimiento porque indica que el 99% de todas las solicitudes se completan dentro de un tiempo específico, mostrando el comportamiento del sistema bajo carga casi máxima. Es crucial para garantizar que la mayoría de los usuarios experimenten un rendimiento aceptable.

La canalización HTTP permite enviar múltiples solicitudes HTTP al servidor sin esperar respuestas individuales, mientras que las conexiones concurrentes se refieren al número de conexiones abiertas que pueden manejar simultáneamente solicitudes y respuestas entre el cliente y el servidor.

Simular escenarios de la vida real en las pruebas de rendimiento es crucial para entender cómo un sistema se comportará bajo condiciones típicas de uso. Esto ayuda a identificar posibles cuellos de botella y a garantizar que el sistema pueda manejar escenarios de usuario comunes de manera eficiente y sin problemas.

Express es una biblioteca para Node.js que facilita el desarrollo de aplicaciones web y APIs al manejar rutas HTTP y middleware de manera más sencilla. Se utiliza definiendo rutas y funciones que responden a diferentes tipos de solicitudes HTTP, como GET o POST.

Para instalar Autocannon, se puede usar el comando 'npm install autocannon -g' para una instalación global. Una vez instalado, se utiliza desde la línea de comandos especificando parámetros como el número de conexiones concurrentes y la duración de la prueba, por ejemplo, 'autocannon -c 10 -d 30 http://miapi.com'.

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.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
How React Compiler Performs on Real Code
React Advanced 2024React Advanced 2024
31 min
How React Compiler Performs on Real Code
Top Content
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio