1. Introducción a la Optimización en Tiempo de Ejecución
Hace muchos años, me encontré con un problema crítico en un gran sistema donde un microservicio tartamudeante causaba retrasos de 2-3 segundos. Como arquitecto de software en Vonage, he dedicado años a optimizar técnicas de tiempo de ejecución. En esta parte, exploraremos cómo identificar y mejorar el rendimiento de las funciones no optimizadas, utilizando un ejemplo sencillo. También discutiremos el impacto de la recolección de basura y la importancia de la optimización en tiempo de ejecución.
Hace muchos años, estaba trabajando en un gran sistema, un sistema crítico de vida o muerte. El sistema funcionaba bien, hasta que un día recibí una llamada de un cliente. Yonatan, dice, el sistema no está respondiendo mis llamadas. Lo que estaba experimentando era un microservicio tartamudeante en el sistema. Había una función no optimizada en el flujo de trabajo que tardaba de 2 a 3 segundos en finalizar en lugar de milisegundos. Para mi cliente, estos 2-3 segundos eran críticos, especialmente al considerar un sistema a gran escala.
Me llamo Yonatan Kra, arquitecto de software en Vonage. Soy instructor de egghead, blogger y un geek a tiempo completo. También disfruto correr. He pasado años optimizando mis técnicas de tiempo de ejecución, lo cual es importante cuando necesitas huir de los matones. Hoy te mostraré cómo detectar funciones no optimizadas y cómo mejorar el rendimiento en tiempo de ejecución en tus aplicaciones.
Comenzaremos mirando un ejemplo sencillo. Aquí tenemos dos funciones que hacen lo mismo. Ambas crean un array y añaden elementos al array. BuildArray1 crea un array vacío y añade dinámicamente los índices al array. BuildArray2 preasigna el array y simplemente establece el valor correcto en el índice correcto. El resultado es el mismo. Veamos su perfil. En su perfil, puedes ver que BuildArray1 tardó alrededor de 40 milisegundos en ejecutarse, mientras que BuildArray2 tardó alrededor de 7 milisegundos en ejecutarse. Esa es una gran diferencia para funciones que hacen lo mismo. Si profundizamos, podremos ver que BuildArray1 tenía muchas barras grises en su interior, y estas son instancias de recolección de basura, mientras que BuildArray2 no tenía estas instancias de recolección de basura. Así es como utilizamos el perfilado para comparar el rendimiento de diferentes implementaciones de las mismas funciones, por ejemplo. Así podemos ver si las mejoras realmente mejoraron nuestras aplicaciones o buscar la solución correcta.
Una palabra sobre la recolección de basura. La recolección de basura es el proceso en el que los motores de JavaScript limpian la memoria de objetos no referenciados. Ya dije que soy corredor, y esta es una buena razón por la que me gusta correr los sábados, porque no hay recolectores de basura los sábados. ¿Por qué deberías preocuparte, en realidad, por la optimización en tiempo de ejecución? Esta es una caricatura del bucle de eventos en JavaScript. Lo que debes entender de esto es que el bucle de eventos está ejecutando tu hilo principal y está ejecutando tareas. Las tareas son en realidad los callbacks, tus funciones. Y si una tarea tarda más tiempo, bloquea el hilo principal y durante esta ejecución de la función, no se está ejecutando nada más.
2. Optimización de Funciones y Perfilado de Rendimiento
Cuando optimizas tus funciones, es importante asegurarse de que se ejecuten sin problemas y evitar retrasos que puedan afectar las llamadas a la API y las promesas. Las herramientas de perfilado como Chrome inspect page y las herramientas de desarrollo dedicadas para node pueden ayudar a identificar y mejorar el rendimiento. El perfilado de memoria también puede revelar fugas de memoria y proporcionar soluciones. Al referenciar claramente los arrays y monitorear las asignaciones, puedes prevenir fugas de memoria y optimizar el rendimiento de tu aplicación.
Entonces, si esta función se está ejecutando, no se están atendiendo las llamadas a la API, no se están resolviendo las promesas y tu aplicación simplemente se queda bloqueada y todo lo demás está esperando. Esta es una buena razón para optimizar tus funciones y asegurarte de que todo funcione sin problemas.
Veamos un ejemplo de eso. Para esto, iremos al IDE. Mira esta función, algo bastante notable. Deberías estar familiarizado, es un array al que se le agregan un millón de elementos y hemos agregado un setInterval que se asegura de que se llame una vez por segundo.
Entonces, si ejecutamos nuestro node con la bandera --inspect, lo siento, inicia node en modo de depuración y podemos ir a la página de inspección de Chrome, abrir las herramientas de desarrollo dedicadas para node y ir a la página del perfilador. Esta vez, comenzaremos a grabar durante dos o tres segundos, finalizamos y aquí vamos. Tenemos nuestros intervalos, uno por segundo, y si profundizamos, en realidad vemos nuestra llamada a algo bastante notable y exactamente cuánto tiempo tardó la función en ejecutarse. De esta manera, podemos perfilar todo en nuestra aplicación de node. Por ejemplo, puedes iniciar una llamada a la API usando Postman y rastrear todo lo que sucede desde el momento en que la llamada a la API llega al servidor hasta que se agota y puedes ver cuánto tiempo tardó cada función en ejecutarse y si ves una función que tarda mucho tiempo, es posible que desees optimizar esta función.
Otro problema en el rendimiento en tiempo de ejecución es la memoria y pronto veremos cómo perfilar la memoria y tal vez incluso solucionar fugas de memoria. En este caso, algo bastante notable, se agrega a un array que se crea externamente, por lo que en cada intervalo, simplemente aumentamos este array y no recolectamos basura del array interno que teníamos antes. Veamos cómo se ve esto cuando perfilar la memoria.
Entonces, comienzo nuevamente en modo de depuración. Esta vez iré a la pestaña de memoria y me aseguro de que la instrumentación de asignación en la línea de tiempo esté funcionando. Comienzo a grabar y veo que aparecen estas barras azules. Una barra azul significa una memoria que se asignó y no se recolectó basura. Y si me enfoco en una de ellas, en realidad veo estos 100 especiales como se esperaba. En cada segundo se asignaron 100 especiales y no se borraron. Si me enfoco en uno de los especiales, puedo ver su índice en el array, el nombre del array de referencia e incluso la línea de código que asignó este objeto. Puedo ver fácilmente si quiero que este objeto se recolecte basura o no. Si quiero que se recolecte basura, entonces tengo una fuga.
Arreglemos esta fuga bastante fácilmente simplemente borrando el array de referencia en cada intervalo. Detendré el servidor, lo reiniciaré y grabemos nuevamente. Ahora, la barra azul se vuelve gris. El gris significa que tuvimos una asignación aquí, pero se recolectó basura. Nuevamente, puedes llamar a tu API, ver si tienes una barra azul que se vuelve gris después de que la API termine de ejecutarse y si no, es posible que tengas una fuga de memoria en el controlador de tu API, por ejemplo.
Por lo general, cuando hablo con desarrolladores sobre el rendimiento o ayudo a los desarrolladores a resolver problemas de rendimiento, veo mucha confusión en cuanto a cómo manejar los problemas de rendimiento. Espero que esta charla te haya ayudado a comprender las herramientas de perfilado que tienes, las poderosas herramientas de perfilado que tienes y cómo puedes ayudar a que tus funciones se ejecuten más rápido y prevenir fugas de memoria en tus aplicaciones. Realmente espero haber despertado tu interés para aprender más sobre este tema. Estoy muy apasionado al respecto y espero que lo disfrutes tanto como yo. ¡Gracias!
Comments