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