Pruebas de rendimiento efectivas para tu servidor con Autocannon

Rate this content
Bookmark

Experiencia en pruebas de rendimiento que se ha desarrollado durante mucho tiempo. Para medir el rendimiento de tu servidor, necesitas una herramienta que pueda simular eficientemente muchas capacidades y darte buenas mediciones según tus criterios de análisis.

La biblioteca de Autocannon NPM me dio exactamente eso: esa biblioteca es súper fácil de instalar y tiene una API muy simple con la que trabajar. En muy poco tiempo, puedes comenzar a hacer pruebas de rendimiento a tu aplicación y obtener buenas mediciones en el entorno de desarrollo y en tus laboratorios de rendimiento, y generar escenarios de prueba complicados.

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

36 min
19 Nov, 2021

Video Summary and Transcription

Tamar es una experimentada escritora y arquitecta de código con experiencia en Node.js. Las pruebas de rendimiento pueden ser confusas, pero entender términos como el rendimiento y el percentil 99 es crucial. El percentil 99 es importante para hacer compromisos y garantizar la satisfacción del cliente. Autocannon es una poderosa herramienta para simular solicitudes y analizar el rendimiento del servidor. Se puede instalar globalmente o usar 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. Introduction to Tamar and her expertise

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 como arquitecta. Actualmente lidero el desarrollo backend en XM Cyber, una startup que simula la actividad de los hackers. Soy experta en Node.js y tengo un profundo conocimiento de su funcionamiento interno. Síganme en Twitter para obtener más información y vean mis conferencias anteriores en YouTube. También soy una violinista profesional y líder de la comunidad en la comunidad de JavaScript Israel. Únanse a nuestros encuentros si están en Israel.

Estoy muy contenta de que hayan venido a mi sesión sobre performance testing con Autocanon. Pero primero, antes de que realmente nos adentremos y hagamos cosas técnicas, me gustaría presentarme. Soy Tamar. Llevo años escribiendo código. Y es mi pasión escribir código. Además de eso, he gestionado grandes grupos de desarrollo y he trabajado como arquitecta en varios lugares. Actualmente lidero el desarrollo backend en una startup llamada XM Cyber. Es una startup realmente genial. Lo que hacemos es imitar la actividad de un hacker en una red informática. Además de eso, bueno, soy experta en Node.js. Mi interés en Node.js comenzó cuando fundé mi propia startup y escribí todo el backend con Node.js. En ese momento realmente me enamoré de esa tecnología. Y comencé a investigarla y a comprender sus partes más profundas. A partir de ese momento me enfoqué realmente en esa tecnología. Y definitivamente es mi favorita. Pueden seguirme en Twitter y 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 comunidad en la comunidad de JavaScript Israel. Organizamos encuentros realmente geniales. Así que si están cerca y si están en Israel y se encuentran con un encuentro de JavaScript Israel, es realmente agradable estar allí. Se recomienda.

2. The Mystery of Performance Testing

Short description:

Hablemos del misterio de las pruebas de rendimiento. Puede ser confuso debido a la terminología y las mediciones poco familiares. 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 de 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 tener en cuenta.

Vale, ahora pasemos a la parte técnica de la charla. Me gustaría hablar un poco sobre el misterio de las pruebas de rendimiento. ¿Por qué lo llamo misterio? Porque la primera vez que realicé pruebas de rendimiento, sentí que estaba escalando una montaña. Fue muy difícil y confuso. ¿Por qué fue tan difícil y confuso? Porque tenía muchas preguntas y todo el mundo hablaba de mucha terminología que no entendía.

Entonces, ¿a qué terminología me refiero? Bueno, cuando haces pruebas de rendimiento, se habla de muchos términos y mediciones con los que no estás familiarizado. Al menos para mí, al principio me dejaron un poco confundido. En primer lugar, el rendimiento. El rendimiento del servidor. ¿Cómo se mide el rendimiento del servidor? ¿Qué significa eso? Puedo simular muchos escenarios de muchas formas. ¿Cuál es la mejor manera de medir realmente el rendimiento del servidor? Además de eso, los usuarios concurrentes. ¿Cómo afectan los usuarios concurrentes a mi escala? ¿Qué es, quiero decir, qué es un usuario concurrente? ¿Qué significa eso? ¿Qué medición es? ¿Cómo simularlo? ¿Cuál es la diferencia entre eso y el pipeline HTTP? Otra cosa que es muy común cuando se habla de pruebas de rendimiento y de benchmarking es el percentil 99. ¿Qué es el percentil 99? ¿Por qué es tan importante? A veces, cuando realizo mediciones y cuando las personas realizan mediciones, nos fijamos mucho más en el percentil 99 que en el promedio. ¿Por qué el percentil 99 es tan importante? Y lo último es el tiempo de respuesta promedio o el tiempo de respuesta. ¿Cómo se mide el tiempo de respuesta? Si debes mirar el promedio o el percentil 99, también se debe tener en cuenta la desviación estándar del benchmark. Todo esto, cuando te encuentras con ellos por primera vez, me dejó muy confundido. Tuve que entender exactamente lo que estaba haciendo para poder simular mi servidor y hacer que las pruebas tengan sentido y realmente mejorar mi rendimiento.

Así que expliquemos un poco todos estos términos, solo un poco a un nivel alto para que puedas entender todo esto. En primer lugar, por supuesto, el objetivo principal de las pruebas de rendimiento es comprender cuánta carga puede manejar nuestro servidor. Por lo general, se trabaja con un contenedor de Docker para realizar pruebas de rendimiento, y luego se simulan solicitudes HTTP a ese contenedor para comprender qué rendimiento puede manejar ese contenedor. Y si ese contenedor puede manejar 100 solicitudes concurrentes, cuando lo duplicas y creas otra instancia, creas otra réplica, puedes manejar 200 solicitudes, y así sucesivamente. Si creas tres réplicas, entonces 300 solicitudes. Pero es realmente importante comprender cuánta carga puede manejar un contenedor de Docker. Una pregunta importante que necesitaba hacerse. Entonces, ¿cuál es el percentil 99 de nuestro tiempo de respuesta? ¿Y cuál es el rendimiento? ¿Cuántas solicitudes concurrentes podemos manejar en promedio? Esas son preguntas muy importantes. Y por qué esas preguntas son importantes. En primer lugar, el percentil 99 del tiempo de respuesta.

3. Importance of the 99th Percentile

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 hacer compromisos con terceros con confianza, 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 observar el percentil 99. Y la pregunta es por qué es importante hablar y observar el percentil 99. ¿Por qué el percentil 99 es tan importante? Entonces, imagina que tienes un compromiso con un tercero, lo que significa que alguien está usando tu sistema y les estás diciendo, escucha, mis solicitudes siempre son más rápidas que, digamos, tres segundos. Si te basaras en el promedio, sabes que no es un data en el que puedas confiar. ¿Y por qué no es algo en lo que puedas confiar? Porque tienes una desviación estándar. Por lo general, la mayoría de tus instancias no están cerca del promedio. Puedes tener instancias que están lejos del promedio. Y en ese caso, en ese caso, es mejor observar 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í, esto es por qué. Y luego estás muy seguro de hacer un compromiso. Te sientes seguro en 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. Entonces, esto es por qué es importante.

4. Understanding Concurrent Requests and AutoCanon

Short description:

La medición promedio de solicitudes concurrentes es crucial para comprender el rendimiento del servidor. AutoCanon es una herramienta que simula solicitudes, permitiendo el envío y control simultáneo de usuarios y tiempo de ejecución concurrentes. Está escrito en Node.js y admite HTTP pipelining, HTTPS y conexiones concurrentes. HTTP pipelining envía múltiples solicitudes simultáneamente sin esperar respuestas, mientras que las conexiones concurrentes simulan usuarios que acceden a un sitio web. AutoCanon se puede instalar y utilizar desde la línea de comandos.

Otra cosa, y creo que esto es lo más valioso para comprender el rendimiento de tu servidor, es la medición promedio de solicitudes concurrentes. ¿Cuál es la cantidad de solicitudes concurrentes que se pueden ejecutar simultáneamente? Aquí estamos hablando del promedio y no del percentil 99 porque en algunos casos o la mayoría de los casos, el percentil 99 representa un pico porque cuando tienes un pico, entonces tu servidor puede tener más. Y la cantidad máxima de solicitudes concurrentes es como tu rendimiento durante un pico. Pero eso también es una medida realmente importante.

Bien, después de hablar de todo eso, hablemos de AutoCanon. ¿Y cómo entra AutoCanon en escena? Necesitas tener una herramienta que pueda simular solicitudes. Estoy hablando de enviar muchas solicitudes simultáneamente. Necesitas algo que te ayude a enviar esas solicitudes simultáneamente. Necesitas controlar la cantidad de usuarios concurrentes. Te gustaría controlar el tiempo de ejecución. 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 escena como una herramienta realmente buena para simular pruebas de rendimiento y hacer pruebas de referencia.

Entonces, ¿qué es AutoCanon? AutoCanon es una herramienta para pruebas de rendimiento y pruebas de referencia. Está escrito en Node.js, lo cual es realmente genial. Está escrito en ese lenguaje. Admite HTTP pipelining para HTTP. Admite HTTPS. Admite conexiones concurrentes. Pero sí, estoy hablando de HTTP pipelining y estoy hablando de conexiones concurrentes. ¿Y sabes qué? Hablemos de qué son las HTTP pipelines y qué son las conexiones concurrentes y cuál es la diferencia entre ellas. Entonces, HTTP pipelining significa que estoy enviando... Bueno, el diagrama está en el lado izquierdo de esta pantalla. HTTP pipeline significa que estoy enviando tres solicitudes y no tengo que esperar a que la primera regrese y luego enviar la segunda. Pero las envío simultáneamente. Las envío sin esperar la respuesta. Entonces, aquí en el lado izquierdo de la imagen, estoy enviando tres solicitudes sin esperar respuesta. Luego, en el lado derecho, tenemos conexiones concurrentes. 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, que se acercan a tu sitio web porque si tienes mil usuarios que se acercan a tu sitio web, tienes miles de conexiones concurrentes. Eso es lo que puedo decir. ¿Cómo se instala AutoCanon en sí? En primer lugar, si quieres instalarlo en la línea de comandos y usarlo desde la línea de comandos, a mí personalmente me gusta mucho usarlo desde la línea de comandos.

5. Instalación y Uso de AutoCANon

Short description:

Para instalar AutoCANon, utiliza NPM para instalarlo globalmente con -g. Esto te dará la herramienta de línea de comandos. Si deseas utilizar la API en tu código JavaScript, instálala como cualquier otra biblioteca. Para Node.js, utiliza npm install AutoCANon --save. Considera instalarlo con --save-dev para propósitos de desarrollo.

Puedes hacer NPM install AutoCANon y luego instalarlo globalmente con -g y así tendrás la herramienta de línea de comandos de AutoCANon. Si deseas utilizar esta API desde tu código JavaScript, entonces puedes hacerlo, es como instalar una biblioteca para un proyecto JavaScript que escribas. Por ejemplo, para Node.js, generalmente haces --save para que esa biblioteca se incluya en tu archivo package JSON. Así que definitivamente puedes hacer npm install AutoCANon --save. Por cierto, en mi opinión, creo que debemos instalarlo con --save-dev y no con --save, porque es una herramienta de desarrollo.

6. Demo de Prueba del Servidor con AutoCANon

Short description:

Veamos este código de 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 en CPU y sincrónico. Probar el servidor con AutoCANon proporcionará resultados para su evaluación.

Pero ahora, después de hablar de ello, me gustaría mostrarte una demostración genial sobre pruebas del servidor con AutoCANon. Y luego mostraremos la versión mejorada del servidor y trataremos de comparar algunos resultados.

De acuerdo entonces. Genial, veamos este código de MyServer. Ok, este es un código de servidor 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 muy 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 de Express. Estoy exponiendo una ruta simple de get con una barra diagonal. Será un HTTP get. Lo que hace esta ruta, bueno, tienes una función de hash aquí. Esto está cifrando una contraseña. Le di una contraseña que es una constante aquí, una contraseña aleatoria como puedes ver. Eso, bueno cuando entras aquí, tienes esta función. Estaba haciendo un algoritmo en criptografía. Está generando un hash para esta cadena que le transfiero usando una sal, una sal aleatoria. Este algoritmo es lo que se llama intensivo en CPU, pero peor que eso, es sincrónico. Si miras aquí, lo estoy usando en una API sincrónica de Node.js. No hay devoluciones de llamada, promesas ni nada por el estilo aquí, lo que significa que se ejecutará dentro del propio bucle de eventos. Y causaría una congelación en mi código.

Así que intentemos probar un poco el servidor con AutoCANon y ver los resultados. De acuerdo entonces. Esta es la línea de comandos. Y creo que la instancia del servidor está aquí. Apaguémoslo y ejecutémoslo.

7. Testing Server Performance and Asynchronous API

Short description:

El servidor está en funcionamiento en el puerto 3000. Autocannon se utiliza 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 el 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 asíncrona 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 conexiones concurrentes. D, como puedes ver, es la duración, y W son los workers. Así que ahora mismo no quiero darle workers. Me gustaría que funcione con C menos D. Vamos a presionar Enter.

Ahora contemos hasta 10. Uno, dos, tres, cuatro, cinco, seis, siete, ocho, genial, tenemos los resultados. Bien, veamos qué tenemos aquí. Primero, veamos la latencia. Aquí está la latencia de esa ejecución, es decir, el tiempo de respuesta. El percentil 99 es de 1.5 segundos. Esto 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 estuvo 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. De acuerdo.

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 mostrarte. Muy bien, entonces, lo siento, vamos 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 asíncrona. Como puedes ver, está aquí. ¿Cómo sabes que es asíncrono? Aquí, hay un callback que se está transfiriendo y resolviéndolo, lo que significa que esto ya no es una operación sincrónica, sino asíncrona 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. Analyzing Server Performance with 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. Ahora, el servidor 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 realizar mejoras.

Entonces, ahora, después de haber visto eso, vayamos a la línea de comandos y, bueno, primero que nada, encontremos 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. Veamos los resultados ahora.

De acuerdo, lo estamos ejecutando durante 10 segundos, ¿recuerdas? Uno, dos, tres, cuatro, cinco, seis, siete, ocho. Muy bien, veamos qué está pasando aquí. En primer lugar, el percentil 99 es de 1.4 segundos, lo cual es mucho mejor que lo que teníamos 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. 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 momentos de mayor carga 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. Así que sí, podemos ver que todas las mediciones han mejorado, lo cual es bueno, pero esto es como una ejecución estándar de AutoCANON y así es como puedo ver el resultado y analizarlo, 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 ejecutarlo nuevamente y ejecutar AutoCANON y ver esas mediciones, como mediciones básicas, y ver si hay mejoras. Muy bien, genial.

Entonces, 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, es que AutoCANON realmente utiliza hilos de trabajo. Espero que estés familiarizado con los hilos de trabajo. Es un modelo genial que se implementó en, comenzó en Node 10, ahora se implementa en, se ha vuelto no experimental en Node 12. Y nos permite ejecutar varios eventos en paralelo. Y bueno, este modelo se utiliza aquí en AutoCannon, lo cual es realmente genial. Entonces, si quieres trabajar con varios trabajadores, puedes hacerlo con la bandera de -W. De acuerdo, comencemos a integrar AutoCANON con nuestro código JavaScript. En primer lugar, el ejemplo básico. Mi objetivo principal es escribir herramientas de prueba, herramientas de prueba geniales que puedan ayudarme a probar mi aplicación. Aquí tienes un ejemplo básico donde obtenemos una instancia de AutoCANON y luego mira lo que estamos haciendo. Simplemente estamos iniciando la ejecución. Al final de la ejecución, lo imprimimos. Aquí tengo 10 conexiones concurrentes. 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. Simulación de Solicitudes y Manejo de Respuestas

Short description:

Puedes usar async await para crear una instancia y esperar a que termine de ejecutarse. Autocannon tiene una API de eventos del cliente que te permite manejar respuestas específicas de la manera que desees. 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 con un código moderno de Node.js. Aquí async await, creando una instancia y esperando a que termine la ejecución y luego imprimes los resultados.

Otra cosa interesante que puedes hacer en tu código con autocannon es que tiene una API de eventos del cliente. Esto significa que puedes recibir un evento y hacer algo con él. Por ejemplo, cada vez que recibas una respuesta específica, puedes manejarla de la manera que desees, lo cual puede ser útil. Así que esta es otra API que es realmente interesante de explorar.

Y lo último, por lo general, cuando quieres hacer pruebas de rendimiento no quieres enviar la misma solicitud todo el tiempo. Te gustaría tener una variedad de solicitudes. Aquí es donde entra en acción la característica de Autocannon con solicitudes, brújula y acción. Aquí puedes ver en el ejemplo que tenemos dos solicitudes. La primera es una solicitud de publicación. Y lo que estamos haciendo aquí es publicar un producto y luego obtener 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. Entonces, 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 datos para él. Así que este es un flujo que puede darte variedad y flujo y múltiples solicitudes. Y esto se acerca más a simular escenarios de la vida real. Esto se acerca más a eso.

10. Consejos para Pruebas de 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, así que estamos muy cerca del final. Aquí tienes algunos consejos para pruebas de escenarios de producción. En primer lugar, algo que al principio no sabía y que cuando me di cuenta, mejoró mucho mis pruebas de rendimiento. Debes asegurarte de que los datos que estás probando sean similares a los que tienes en producción, lo que significa que si tienes una colección de un tamaño específico, asegúrate de que los datos simulados que estás utilizando para las pruebas también tengan el mismo tamaño, que los campos en producción sean idénticos a los campos que existen en tu base de datos, que aparezcan en tu base de datos, y sí, y observa tus flujos de producción e intenta simularlos tanto como sea posible. Eso es todo, espero que mi charla te haya dado algún conocimiento sobre las pruebas de rendimiento y espero que explores un poco AutoCanon para intentar escribir tus propias pruebas de rendimiento para tus pruebas existentes. Eso fui yo, este es mi nombre de usuario en 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 nos movemos en línea. Las pruebas de estrés y carga son cruciales para comprender la capacidad del servidor y asegurarse de que no colapse bajo un tráfico máximo. AutoCanon proporciona flexibilidad al escribir escenarios de prueba y se prefiere sobre Gatling. Si tu computadora carece de potencia, considera orquestar un conjunto de computadoras para ejecutar AutoCanon.

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

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

Sí, también hay muchos tipos de pruebas de rendimiento, hay pruebas de estrés, pruebas de carga, pruebas de tráfico máximo. 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 sin publicar nada más, porque no está probado adecuadamente, 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 te ayuden a hacerlo de manera muy eficiente, es decir, es muy importante hacer pruebas de rendimiento, pruebas de estrés, para comprender cuánta carga puede manejar tu servidor. Y también es realmente importante comprender, sabes, si tienes una cantidad específica de tráfico, y luego, de repente, tienes un pico, es muy, muy importante asegurarse de que tu servidor no colapse. Quiero decir, en los picos, hay muchos otros problemas como el escalado automático, como ver que tomas otras instancias de tu servidor rápidamente y que tus usuarios obtengan respuestas rápidas. Así que creo que si hablamos de priorización, por supuesto, las pruebas de estrés y carga son, en mi opinión al menos, las tareas con las que deberías comenzar y luego deberías pasar a las pruebas de tráfico máximo.

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

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

Bueno, tengo que decir que generalmente no trabajo con Gatlings porque en realidad lo bueno de AutoCAD es que como desarrollador, puedo escribir lo que quiera, como escenarios y todas las cosas que, ya sabes, bueno, la persona que hizo esta pregunta preguntó cómo construir escenarios de prueba. Así que me siento muy cómodo haciéndolo en código. Y así, en realidad, prefiero la flexibilidad de AutoCAD en cualquier escenario que desee. 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 manejar el servidor, ¿qué debo hacer? ¿Debo orquestar un conjunto 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 ejecutar 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 nube y puede construir un clúster en la nube y desplegar el software que está probando 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 entenderlos correctamente. ¿En dónde? Cypress. Oh sí, lo siento. En realidad, no intenté integrarlo con Cypress, para ser honesto, pero si, bueno, puedes hacer integración de código en cualquier lugar. No debería ser difícil. Sí, estoy de acuerdo. Y también, en este caso, hiciste una prueba, tal vez puedan informarnos después.

Y tal vez una última pregunta, creo que tenemos tiempo. ¿Lo estás integrando en un CI o ejecutando pruebas de rendimiento continuamente, como una vez al día o en cada despliegue? Bueno, personalmente apoyo el enfoque de ejecutar pruebas de rendimiento una vez al día, digamos, y no en cada CI, porque, creo que ralentiza un poco el desarrollo. Por supuesto, tiene la desventaja de, ya sabes, no saber en qué confirmación específica se rompieron las cosas. Pero creo que el desarrollo es más rápido cuando se ejecuta una vez al día. Oh, esa es una opinión interesante. Porque en estos días, todo se empuja a ser como DevOps, KOps, todo se integra en el flujo continuo. Y tal vez deberíamos simplemente- Lo que pasa es que esta tarea lleva tiempo. Y, ya sabes, al menos en X y cyber, tenemos un gran CICD, eso es muchas cosas. Y en realidad es muy eficiente y encuentra muchos errores. Pero esta tarea específica lleva tiempo. Sí, significa que un desarrollador tendría que esperar unas horas. Agrega unas horas a todo. Lleva tiempo. Sí, definitivamente. Y tienes que equilibrar la calidad y el tiempo invertido. Muchas gracias Tamara por unirte a nosotros. De acuerdo, genial. Muchas gracias por estar aquí. Y gracias por la gran charla. Fue agradable tenerte 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

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
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
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.
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 Summit 2023React Summit 2023
23 min
React Concurrency, Explained
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
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
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.
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 Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
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.
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
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.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- 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
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
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