Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
Primero le echo la culpa a WordPress.
no? es lo que todos hacen no, pero ya en serio
¿por dónde empezaría yo? Como desarrollador, yo diría que yo empezaría antes incluso de que falle. Este es un consejo, incluso si no ha fallado nada, si todo está bien, mi consejo es agreguen logs para todo. Los logs nos van a indicar qué es lo que está haciendo el servidor, cuánto se tarda en hacerlo y en qué partes falla
Douglas (00:36)
sean bienvenidos a un episodio más de Dev & Ops, esta vez con un tema un poco más técnico que esperamos que sea de provecho para muchos de ustedes. Juan, bienvenido.
Juan (00:49)
Hola Douglas y hola a todos los que nos están escuchando.
Muy bien, sí, la verdad es que este tema me gusta mucho, me gusta la idea de poder tocar temas que son un poco más técnicos. Es un poco complicado, estábamos hablando al inicio de cómo hablar o dar consejos sin tener una guía visual, porque hay muchas personas que nos escuchan y sin estar viendo nada, ¿no? Pero aún así, me agrada la idea de este nuevo tema que vamos a ver y no sé, Douglas, tal vez nos podrías dar un poco más contexto de qué vamos
hablar el día de hoy.
Douglas (01:25)
por supuesto,
y me alegra como siempre vos, Juan, con la mejor actitud y tratando de sobreponerte a las adversidades. Definitivamente uno de los retos más grandes que hemos discutido en este espacio, de qué compartir en este espacio, en este podcast, es cómo transmitir ideas y conocimientos más técnicos en este formato sin ayuda visual para aquellos que nos escuchan por plataformas de
de audio streaming únicamente. Y el tema de hoy es algo que puede llegar a ser bastante práctico y que requiera de mucha ayuda audiovisual. Sin embargo, vamos a ir por el proceso que vos y yo seguiríamos. Y es cómo identificar o cómo hacer troubleshooting cuando una aplicación o un sitio web está lento.
Yo creo que todos hemos pasado por esa situación en la que entramos a la página web de tu tienda favorita en línea o querés ver algo en las páginas oficiales del gobierno o de la alcaldía, la municipalidad o simplemente estás haciendo una aplicación o un proyecto en tu colegio o en la universidad.
Y cuando entras a la aplicación es extremadamente lenta. Tarda un montón simplemente encargar la página principal, el home page. Y cuando se le da click a algo, te levantas, vas a tomar agua, regresas y tal vez con mucha suerte ya está cargando. ¿por qué una aplicación, una página web se vuelve lenta? ¿Y cuál es el proceso, Juan?
que vos, como programador, seguirías para tratar de identificar ese problema y obviamente luego de identificarlo buscar solucionarlo, buscar repararlo. Aparte, ¿cómo sería ese trabajo de colaboración entre el desarrollador y el de infraestructura y operaciones para encontrar el problema y solventarlo? Entonces...
Juan, desde tu perspectiva, la mayoría de las veces si esto es un proyecto en una empresa, el jefe del departamento o un project manager va a ir, la aplicación está lenta, a ir donde el programador. Juan Mirabe, la aplicación está lenta. ¿Cómo procedes?
Juan (04:01)
Primero le echo la culpa a WordPress.
no? es lo que todos hacen no, pero ya en serio yo diría que es complicado y más cuando digamos no tienes mucha experiencia te has esforzado mucho en hacer una aplicación y tal vez lo probaste en tu PC y funcionaba de maravilla y ya en el servidor es donde ya empieza a mostrar sus verdaderos colores y ahí es un poco difícil porque no tenemos idea ni por donde empezar
Entonces,
¿por dónde empezaría yo? Como desarrollador, yo diría que yo empezaría antes incluso de que falle. Este es un consejo, incluso si no ha fallado nada, si todo está bien, mi consejo es agreguen logs para todo. Los logs nos van a indicar qué es lo que está haciendo el servidor, cuánto se tarda en hacerlo y en qué partes falla o en qué partes, digamos que
tal vez algo, un query de la base
no me retorno lo que yo necesitaba o lo que yo quería pero sin los tal vez no me doy cuenta entonces lo primero sería revisar los logs y de antemano haber hecho estos logs haber agregado logs por todos lados eso sería lo primero ir a revisar los logs por todos lados porque hoy en día hay muchas herramientas que tal vez más adelante vamos a poder listar algunas que nos pueden ayudar a ver métricas de la aplicación
basados en los logs, solo basados en texto que estamos lanzando a la terminal y este texto lo está capturando otro servicio, otra aplicación y nos va ayudar a poder verificar qué está pasando. que tener paciencia porque a veces como dije no sabemos por dónde empezar entonces lo mejor es tranquilizarnos, que calmarnos como dice el meme y empezar a ver ok que si yo llame a este endpoint, si es un web service, si yo llame a este endpoint
que es lo que tuvo que haber sucedido y revisar en un logs que fue lo que sucedió entonces ese sería mi punto de partida para empezar a revisar cualquier fallo que pudo haber sido todavía no sabemos si hay que optimizar no sabemos si hay que cambiar algo alguna dependencia no sabemos nada entonces lo primero es recolectar toda la información que podamos para poder ir a empezar a tomar decisiones eso sería lo primero que yo
haría
Douglas.
Douglas (06:34)
Sí,
entiendo Juan y realmente creo que lo que estás tratando de decirnos es que sin suficiente login para tratar de encontrar el problema o para tratar de debugging como se dice en nuestra área es bien complicado. Es como tratar de comunicarnos sin hablar.
no vamos a poder transmitir la idea. Y desde mi lado, Juan, como alguien de infraestructura, como alguien de operaciones, mi primer reacción cuando me entero que una aplicación está lenta es pedirle al desarrollador que revise el código. En paralelo, yo estoy haciendo otras cosas y ya las vamos a mencionar.
No es que yo estoy tirándole la pelota al desarrollador, pero muchas veces, y he tenido tantas experiencias, muchas veces desde el diseño, la arquitectura del código, loops anidados, una cadena de 10 a 15 if statements seguidos, que cuando corrian en el local del desarrollador, tal vez un desarrollador junior, él sentía que la respuesta era inmediata, pero...
decenas de esos requests de ese código corriendo o cientos o miles de requests de llamados a ese mismo código se vuelve un cuello de botella muchas veces revisar ese código y más allá están las otras herramientas que vos nos dijiste de instalar para debugging y en este caso tenemos la observabilidad de los logs
que está retornando la aplicación cuando recibe un request, que está devolviendo la aplicación, que está devolviendo el application server, que está devolviendo el web server. Pero también tenemos otro tipo de métricas que se le conoce como el APM o el Application Performance Monitoring, que son estos tools que devuelven métricas internas de la aplicación. Cuanto tarda la aplicación en ir a la base de datos y devolver el query o cuáles son los queries lentos. Entonces, este tipo de cosas que nosotros
infraestructura buscamos que estén listas e instaladas en un servidor y trabajamos en conjunto con los desarrolladores para que puedan facilitar este tipo de cosas.
Otra de mis experiencias, Juan, y tal vez no sé si vos tenés más que agregar aquí, pero otra de mis experiencias ha sido con la base de datos. A veces queries lentos, join tables demasiado, falta de índices, perdón, donde se está haciendo. muchas veces la base de datos llega a ser un tremendo cuello de botella. ¿Cómo normalmente vos identificas?
o buscas ese tipo de problemas.
Juan (09:38)
Si, definitivamente he tenido muchos problemas con la base de datos en el pasado en diferentes aplicaciones porque la verdad es que la base de datos es algo que existe y siempre va a existir porque necesitamos guardar la información. Me gustaría dar un paso atrás antes de llegar a la base de datos porque como mencionaba, lo primero es recolectar información desde el punto de vista de desarrollador, incluso en el lado de operaciones también. que visualizar lo que al inicio estábamos
como si estuviéramos en un bosque oscuro y sólo tenemos una linterna entonces tenemos que empezar a buscar y alumbrar y para poder encontrarle el camino otra herramienta que nos va ayudar a hacer esto ya teníamos los logs la otra es hay herramientas que nos permiten hacer un perfil de toda nuestra aplicación que nos permite ver por ejemplo de todos los procesos que hace nuestra aplicación donde estamos utilizando más memoria ram o más
proceso, más procesador. En Go donde tengo un poquito más de experiencia es un poquito fácil diría yo porque ya trae unos paquetes integrados o dentro de la librería estándar hay uno que se llama pprof y esto nos permite mapear todo el proceso de la aplicación esto lo podemos habilitar en el servidor y esto nos genera un que un archivito que podemos luego nosotros revisar
En otros lenguajes también existe, tal vez no son parte de las librerías estándar de dichos lenguajes, por ejemplo en C sharp, en Python, en Node.js, podemos descargar librerías externas, librerías de terceros, que nos pueden ayudar a hacer exactamente esto. La idea aquí es recolectar información y empezar a analizar un poco de qué está sucediendo. Empezar a ver, ok, mi aplicación, al momento de crear un usuario.
veo que en este apartado donde estoy haciendo un índice de diferentes perfiles de este usuario veo que estoy haciendo mucho uso de memoria lo cual yo no esperaba tal vez. Entonces este tipo de herramientas definitivamente nos van a ayudar a empezar a entender cómo se está comportando nuestra aplicación y de esa forma vamos a poder ser más eficientes a la hora de encontrar una respuesta.
ya después de eso, que tal vez el profile o el perfil de nuestra aplicación está bien y no encontramos nada sospechoso. Ahí entonces podríamos ir a la base de datos como mencionabas y en este caso lo primero que yo haría es tal vez revisar primero que nada los índices como mencionabas, algo básico, si tenemos una tabla y hacemos un select asterisco from y en el where estamos utilizando tal vez
columnas de esta tabla que no tienen índice y los estamos utilizando muy seguido entonces tal vez lo ideal sería crear un índice para este tipo de búsquedas y luego algo tal vez un poquito más no sé si avanzado sería la palabra pero la mayoría de motores de SQL tienen el comando explain sí creo que se le dice comando sería un comando que nos permite ver todo el query como el motor de
la base de datos está analizando nuestro query, cómo se va a comportar y esto también nos da mayor información para poder optimizarlo, para poder cambiarlo. De nuevo, la clave aquí es conseguir información de qué está pasando. Ese sería el tema que se empieza a repetir aquí.
Douglas (13:27)
Sí, perfecto. Intentar identificar dónde están los cuello de botellas para buscarle solución. Y ya nos mencionaste que para eso hay preparativos a nivel de código, asegurarnos que estén los logins correctos. Hay preparativos en conjunto con la gente de infraestructura, asegurarnos que tenemos las herramientas correctas para loguear esto, para recolectar estas métricas.
y luego lo de la base de datos. Una herramienta, Juan, que yo uso mucho y es para tratar de identificar estos diferentes llamados en el código, yo como alguien de infraestructura lo uso mucho cuando estoy tratando de identificar dónde puede haber un cuello de botella, son los developer tools del navegador.
Me voy al Network Tap, a la ventanita donde están los diferentes llamados y le doy Refresh y trato de ver cuáles son los que toman más tiempo. Y solo viendo ahí y cliqueando los llamados, a veces los headers que devuelve.
o los diferentes errores que se pueden encontrar ahí, muchas veces se encuentra que tenés una dependencia a una librería externa o a un servicio externo que tal vez ese día está caído o está lento, en ese momento está pasando por algún tipo de problema o está simplemente un servicio que es muy lento, que no depende de mí, puede ser un llamado a una aplicación que siempre es de la misma compañía pero que no maneja mi equipo y tal vez es allá donde está el cuello de botella y en muchas ocasiones usando
Juan (14:43)
Sí.
Douglas (15:02)
esa herramienta tan sencilla que está en el navegador de todos nosotros, logro ver cuáles son los los requests que están tomando más tiempo, pero creo que entonces Juan que al final podemos concluir que el primer lugar o uno de los primeros lugares al cual ir a hacer troubleshooting
cuando una aplicación está lenta es al código y a lo relacionado con el código para ver que está lo más óptimo posible.
Juan (15:36)
si definitivamente yo
si veo que nuestra aplicación está fallando, claro que me pondría en contacto con, en este caso, la persona de operaciones, el DevOps, el administrador del servidor, como sea el puesto. Pero, definitivamente, mi primera reacción es revisar el código. Eso lo que podemos hacer definitivamente. Y ya después empezamos a utilizar estas herramientas que estamos listando. Sí, definitivamente, también los Developer Tools de los navegadores
son muy beneficiosos. Yo suelo utilizar el de Firefox, no sé por qué me gusta más el de Firefox, no sé si será costumbre. Suelo trabajar con Chrome, pero al momento de utilizar el Developer Tools prefiero el de Firefox, no sé por qué. Pero sí.
Douglas (16:27)
Bueno, vos sos programador y
creo que le encontrás beneficio o que mejora tu flujo de trabajo. En mi caso, como alguien de operaciones, con el de Chrome tengo lo que necesito. ¿Verdad?
Juan (16:40)
Da igual,
Sí.
Douglas (16:45)
Sí, yo creo que por esa parte de tu lado, y estos son estos temas de inclusive tu IDE, cuál es el más rápido, cuál es el más lento, y esta es una guerra que se encuentra ahí por internet al final del día, creo que los programadores que están más tiempo en código tienen el privilegio de tener esos gustos, si lo podemos llamar de esa manera. Pero muy bien Juan, fíjate que...
Juan (16:54)
Sí.
Sí, sí, sí.
Douglas (17:15)
Yo creo que estableciendo que el código es de lo primero que tenemos que ir a ver, yo como alguien de infraestructura, de manera paralela, también me voy a la configuración del servidor. Cuando me refiero a la configuración del servidor, y aquí va a variar un poco dependiendo en qué tipo de ambiente está corriendo la aplicación, es un servidor físico.
si es una computadora que está a los pies de la gente de sistemas, desde ahí están corriendo todo, verdad, o si es una instancia pequeña en la nube o pudiera ser un cluster entero o contenedores, ahí va a variar, pero me voy a la configuración del servidor
principalmente si esto sería una aplicación... Hoy en día, aunque tengas una aplicación móvil, ejemplo, va a depender de REST API, va a depender de llamados, APIs con ciertas respuestas. Entonces, me voy ir a la configuración del web server, a la configuración del application server. Y para quienes no entiendan, el application server es el que ejecuta la aplicación Tu Código.
el que ejecuta el proceso, si es una aplicación de Golang, que ejecuta Golang, si es una aplicación en PHP, el que ejecuta el código de PHP, si es una aplicación de Node.js, el Application Server sería el que ejecuta tu código de Node.js y el Web Server sería aquel encargado de servir el contenido web, imágenes, contenido estático, el que renderiza HTML.
CSS y esas cosas, me iría a esa configuración, asegurarme de que está bien, de que está consumiendo todos los recursos del servidor sin hacerlo quedarse en memoria, porque a veces tenemos un servidor o un cluster con suficientes recursos pero el web server o el application server lo configuramos a que solo use una fracción de él, ¿verdad?
está bien configurado o a veces se le puso demasiado y está haciendo que consuma toda la memoria y el servidor es ahí donde se pone lento, primero el primer paso mío es irme a estas configuraciones en el servidor y asegurarme de que todo esté bien. Por tu parte como desarrollo Juan, ¿qué buscas colaborar?
con la gente de infraestructura cuando tiene que ver con la configuración del servidor porque ya viste tu aplicación, ya viste que está en base a los recursos que tenés y en base a las herramientas que te dieron, está lo más óptimo posible de tu lado. ¿Cuáles son las cosas que vos buscas colaborar con infraestructura de nuevo con respecto a la configuración del servidor o el ambiente en el que está hospedada la aplicación?
Juan (20:16)
Sí, aquí es donde ya empezamos a, como mencionabas al inicio, de hecho desde que empieza a fallar algo, empezamos a colaborar, pero tal vez al inicio es un poquito más esporádico, cada quien por su lado, pero nos damos cierta retroalimentación de, ok, yo voy a revisar esto, vos revisas lo otro. Pero si aún así, tal vez no encontramos qué está pasando, empezamos a probar más cosas, y aquí es donde empezamos como a colaborar un poco más.
más pegados, más juntos. Yo diría que algo que yo suelo preguntar a las personas encargadas de todo lo es la configuración del servidor, asumiendo que no soy yo, que no soy yo el que estoy configurando, sería muy similar a lo que mencionabas de los recursos. Si es un ambiente dockerizado o de contenedores, ¿cuánta memoria estamos asignando?
Douglas (20:50)
Mhmm.
Juan (21:16)
a cada uno de los contenedores, con cuánta memoria inicializa, todos estos apartados que son de los recursos a veces necesitamos revisarlos para ver que la aplicación funcione como esperábamos, de por sí, lo normal sería que no necesite tantos recursos, pero siempre es bueno al menos saber, a veces es información que tal vez no nos
llegan los desarrolladores entonces si no lo sabemos por ahí empiezo empezó a preguntar cómo está configurado también otra cosa que me gusta saber o empiezo a preguntar es similar a lo que mencionabas de si una aplicación está utilizando muchos recursos si dentro del mismo servidor estamos corriendo múltiples aplicaciones de nuevo cuánto está utilizando los demás tal vez
no
suele ser tan seguido, suceder tan seguido, pero a veces tal vez el problema no es de mi aplicación sino que otra aplicación está consumiendo todos los recursos y eso hace un efecto de bola de nieve que hace que luego mi aplicación no tenga los recursos que necesita tal vez tiene un proceso que es muy intenso pero para poder hacerlo ya no tiene memoria entonces también empiezo a revisar cómo están están interconectados los servicios dentro del servidor
Douglas (22:33)
No, no.
Juan (22:46)
las instancias. Entonces, yo empiezo como a preguntar cuáles son las configuraciones, cuáles son los recursos que tiene, cuáles son los límites que están configurados para de nuevo, para poder ir tomando ciertas decisiones y ir también descartando problemas para saber si realmente no es un problema de recursos. Yo por ahí iniciaría. Y luego ya podemos empezar a colaborar un poco más y empezar a hacer cambios.
Douglas (23:12)
Sí.
Juan (23:16)
cambiamos esto, cambiamos lo otro.
Douglas (23:18)
de
ser necesario y me llama la atención lo lo que está mencionando Juan y viene afirmando lo que estamos diciendo del orden de cómo abordar este troubleshooting o esta investigación para identificar por qué una aplicación a un sitio está lento porque cuando estás convencido de que tu código está bien
de que la base de datos, los queries, la estructura está lo más óptimo posible, de que estás recolectando toda la información necesaria, pasamos a la parte del servidor y vos mencionas, ¿qué más hay corriendo ahí? ¿estará afectando mi aplicación? Pero a ese punto ya te sentís seguro de preguntar eso, porque ya descartaste primero tu código, tu aplicación, y de nuevo esto afirma el orden...
muchas veces si supiéramos qué es de entrada y nos brincamos los primeros 20 pasos vamos a encontrar más rápido pero y si me equivoqué o muchas veces se generan errores que son bien comunes y tal vez así como vos o como yo que por gracias a dios tenemos bastante experiencia en la industria hay mucho error que yo no ha terminado de encontrarme el developer y ya sé que es por
porque me he enfrentado a él x cantidad de veces, lo común estamos tratando de ejemplificar un error nuevo, este orden es el que seguiríamos ambos y en esa parte estamos de acuerdo. Algo más que yo vería en la configuración del servidor, sería la configuración entre el web server y el application server. Yo creo que ya lo aclaré hace unos minutos.
Juan (24:38)
de Vietnam.
Douglas (25:03)
pero muchas veces se está configurando un servidor, una aplicación, pongamos de ejemplo Golang, vos tenés experiencia Golang, y estamos renderizando imágenes y no nos fijamos que tenemos a Golang sirviendo HTML y CSS e imágenes estáticas a los usuarios.
Cuando Golan realmente, la intención del web server que levanta Golan es para llamadas, APIs, para retornar un JSON file, para retornar ese tipo de respuestas y no en realidad ese contenido web que se necesita, ese contenido web para la apariencia de la aplicación. Y es ahí donde tenemos que asegurarnos de tener.
un layer arriba, un web server como Nginx, Nginx que hace, recibe todas las conexiones web y primero verifica si es un contenido estático, es un file CSS, si es un JavaScript y si es ese tipo de archivo Nginx lo va a servir directamente porque el web server está diseñado para servir ese tipo de contenido y si es una llamada a la aplicación Nginx va a ser reverse proxy, va a
redirigir ese tráfico al application server, verdad? Entonces, de nuevo muchas veces me he topado con que está mal configurado el servidor de esa manera y si tenés el application server sirviendo contenido estático, el rendimiento de la aplicación realmente se va ver bastante afectado. Entonces...
Juan (26:50)
Entonces
recomendarías NGINX aún si tuviésemos una aplicación monolítica que es una sola aplicación, no tenemos que hacer digamos un routing interno para que llame diferentes servidores, servicios perdón, aún así nos tendríamos mucha ventaja o muchos beneficios utilizando NGINX, eso es lo que te entiendo.
Douglas (27:13)
absolutamente Juan, mira, esto es como querer ponerme a mí a desarrollar el backend en Golang cuando yo soy alguien de operaciones y te tenemos a vos como experto en backend en APIs. Nginx, ese es su fuerte.
servir contenido estático. Un web server en general también está Apache, que es súper usado, pero hoy en día el que todos prefieren o el que la mayoría prefiere, voy a plantearlo de esta manera, es NGINX, pero el web server está diseñado para servir contenido estático. Tiene diferentes...
herramientas, diferentes implementaciones que te permiten configurarlo y servir de manera muy óptima todo lo que tiene que ver con contenido estático. De nuevo HTML, JavaScript, esa es su función. Entonces le dejamos al web server esa función de servir contenido estático y entonces el monolítico, la pregunta que me estás haciendo, ¿verdad? Solamente los llamados...
que van a hacer procesamiento de backend, que van a hacer cualquier cálculo, llamados, en este caso sería si tu aplicación es PHP, llamados a los archivos PHP, si tu aplicación es Node.js, los llamados a los endpoints de Node.js o si es Golang, los llamados a los endpoints de Golang, ahí es donde NGINX o el web server que decidas usar va mandar ese tráfico únicamente, ese tráfico únicamente al web server. Entonces de esa manera vamos a tener al web server.
haciendo operaciones lógicas, perdón, vamos a tener el application server haciendo operaciones lógicas que para eso es el application server y vamos a tener al web server sirviendo todo el contenido estático que para eso está diseñado.
Juan (29:13)
Excelente.
Excelente, utilizar la herramienta correcta para cada uno de los casos. Excelente. Me gustaría también, OK, siguiendo con los temas de qué hacer y qué revisar, otro tema que también me gustaría mencionar en el caso que tengamos una aplicación contenerizada, Docker, Podman, cualquiera de estas,
Douglas (29:22)
Sí, sí.
Juan (29:44)
Es revisar nuestro archivo, el famoso Dockerfile, porque creo que ya lo mencionado antes que es importante optimizar estos pasos para tener una imagen de Docker muy liviana, eso nos ayuda a la latencia, al momento de transferir esta imagen en los servidores. Pero otra ventaja que también podemos encontrar, ya aquí está hablando de optimizaciones, es el hecho de que a veces utilizamos una imagen
que no solamente es pesada sino que también trae otras librerías que no son las que realmente necesitamos o a veces en los pasos configuramos algo que se pueda quedar corriendo por detrás en los servicios entonces yo lo que siempre recomiendo es tener múltiples pasos y múltiples capas dentro del Dockerfile o lo que se le llama el multi-stage así la última
el último paso en el Dockerfile nos podemos enfocar en ok aquí va a estar una imagen limpia donde en teoría sólo estar mi corriendo mi aplicación o mi servicio y de esa forma de nuevo empezamos a descartar cosas que no las vamos a necesitar y que por a o por b podrían llegar a entrar en conflicto con algo de lo que de lo que tenemos en nuestra aplicación y si eso es algo que yo
que suelo revisar también ganamos cierta mejora en los procesamientos de nuestra aplicación
Douglas (31:23)
Sí, es un error muy común, pensar que porque mi aplicación está en GoLang, que GoLang tiene que estar instalado en la imagen de Docker final, cuando en realidad solo necesito GoLang para el build process y que me genere un binario, pero una vez que el binario está ya generado...
Juan (31:45)
Sí.
Douglas (31:45)
Necesitamos
una imagen de Linux, puede ser Linux más liviano posible, Alpine y solamente ejecutar el binario y es ahí donde el multi-stage que nos mencionas viene a ser muy útil. Igual lo veo muy común en aplicaciones de Node.js, por ejemplo.
Juan (31:52)
Sí.
Mm-hmm.
Douglas (32:06)
verdad,
donde se instalan múltiples librerías para desarrollo que terminan en producción y no eran necesarias y ese tipo de procesamiento corriendo en el fondo o en el background nos afecta en el performance. Entonces muy de acuerdo con vos, cien por ciento de acuerdo con vos en esa área Juan y me gustaría que sigamos avanzando. Ya estamos en un escenario donde analizamos el código.
y analizamos la configuración del servidor y vemos que acorde a lo que tenemos, acorde a las herramientas, acorde al lenguaje que estoy utilizando, etcétera, tengo todo lo más óptimo posible, sin embargo, la aplicación o el sitio sigue lento, o mejoró un poquito, pero no lo suficiente. A ese punto...
entramos a una situación en la que lo primero que yo pienso es, entonces faltan elementos a mi aplicación, entonces falta algo. Estoy usando de la mejor manera posible los recursos que tengo, pero entonces falta algo. Y de las primeras cosas que yo miro para intentar agregar a una aplicación es caching.
because many times we are doing the same call over and over again and generating the same process to the application server or calling the same query over over again to the database and that is computer time on your server
que a los segundos, a veces milisegundos se va a volver a repetir o aunque sea a los 30 segundos o un minuto se va a volver a repetir y si es el mismo proceso ¿por qué volverlo ejecutar otra vez? entonces la y este es el punto Juan en lo que mi experiencia personal el 85 % de los casos cuando una aplicación está lenta es la falta
de caching y de nuevo la intención del caching es evitar que estos procesos se estén repitiendo que el mismo proceso se esté repitiendo una y otra vez y cuando se trata de caching entre más cerca del usuario está es mejor
obviamente va a depender de la situación, del escenario, pero entre más cerca del cliente es mejor. Muchas veces, si estamos hablando de una aplicación móvil, muchas veces se puede almacenar el caché de manera local en el dispositivo, algún llamado a un servicio que nosotros sabemos que no cambia seguido, o imágenes o contenido estático se pueden almacenar de manera local.
para que no se tenga que estar haciendo la comunicación por internet de nuevo para volver a llamar el mismo que por las siguientes dos semanas, tres semanas, a veces mucho más tiempo, ese contenido no va a cambiar, entonces no hay necesidad de estarlo yendo a llamar cada vez. O si es una aplicación web o un sitio web con los headers correctos, se le indica al navegador web.
que deje ese contenido cachado de manera local en tu computadora o puede ser siempre tu celular si estás accesando la web desde tu celular. Pero si podemos cachar a nivel del cliente, obviamente tiene que ser información que no sea sensitiva, que no contenga nada personal. Ese ya es otro tema en cuestión de seguridad. Pero comenzar...
cachando lo más cerca del cliente. Y otro caching que voy a mencionar antes de tal vez que nos conté su experiencia con qué implementaría VOS con respecto a caching es lo que se conoce como el Edge Caching o CDN.
que es cachar a la orilla o lo más cerca del usuario. Un CDN es este servicio que tiene diferentes servidores en diferentes partes del mundo y busca servir el contenido al usuario desde los servidores que están más cerca de él. Si nosotros estamos en Centroamérica, entonces busca servidores que estén o lo más cerca de Centroamérica, ya sea aquí mismo en Centroamérica o si no, tal vez en zonas cercanas de Estados Unidos, que puedan llegar más rápido la gente que esté en Europa, les sirve
su contenido desde Europa y en un edge caching o en un CDN vamos a cachar cosas como imágenes, cosas como contenido estático, CSS que no cambia mucho o incluso hasta respuestas de un API que nosotros sabemos que no va a estar cambiando constantemente parece parece poco pero mucha gente no entiende el poder que tiene muchas veces
cachar por 15 segundos, 30 segundos una respuesta a un API, ¿verdad? Que lo usa una, que en ese tiempo recibe 200, 300, 1000, 2000 llamados.
y que esté cachado por 15 segundos, el impacto que tiene en el performance de una aplicación es extremadamente grande. Entonces, ¿cuánto tiempo cachamos la información? Va a depender del tipo de contenido, pero en general vamos a buscar...
cachar la información y de esa manera quitarle esa carga a los servidores, quitarle esa carga al application server, quitarle esa carga al web server y que quede lo más cerca del usuario posible. Entonces, en cuestión de caching, ¿cuáles son las áreas que vos como desarrollador normalmente ves o buscas?
Juan (38:06)
Bueno, el tema del caché...
desde mi punto de vista no es tan simple lo menciono porque muchas veces me he topado con comentarios de gente por todos lados que mencionan bueno si cachar lo guardas en redis lo guardas en memcache y listo y no no es tan fácil cachar información yo lo digo así cachar tiene de entrada dos problemas o dos diferentes
dificultades mejor dicho la primera es identificar qué información puedes guardar en un caché como mencionabas primero que nada lo ideal es que no sea información sensitiva aunque si lo haces del lado del servidor tal vez tenés un poco más de flexibilidad en ese aspecto la otra dificultad con la que yo siempre me he topado es cómo invalidas el caché también porque a veces puedes guardar un caché pero llega cierta operación o se ejecuta algo en el servidor y ahora esa
información que tenias en el cache ya no es valida entonces tenes que invalidar ese cache y volverlo a generar entonces ese juego de estar cachando y invalidando el cache a veces se puede tornar bien complejo se puede hacer una sopa en el código que puede ser bien complicado en general bueno yo lo que mencionaria es que
que revisar qué cosas son las que ejecuta constantemente un usuario y qué cosas se ejecutan constantemente por muchos usuarios. A veces yo me he topado con ciertos casos donde hay una información que se calcula pero esta información ya calculada realmente le sirve a múltiples usuarios no solamente a uno. Entonces ahí esa es una
oportunidad para introducir este resultado en el cache de nuestra aplicación porque lo que hizo uno cuando una persona ejecutó este request ese resultado ahora le va servir a los demás entonces es un poquito complejo a veces pero si logramos identificar eso como mencionabas es un impacto tremendo en el performance que va a tener el servicio o la aplicación al final luego identificar
para
información en un dashboard de una aplicación y este dashboard lo calculas por fechas entonces lo que calculaste el día de hoy como es por fecha no te interesa la hora te va a servir por todo el entonces ya ahí te da pie para que puedas guardar esta información en el caché por más tiempo tal vez minutos incluso horas entonces ir identificando este tipo de cosas como guardar el caché por cuánto tiempo guardarlo es es crucial
luego viene la siguiente parte este cache donde lo guardo mencionabas lo de utilizar mucho el cache de los headers de los CDNs pero que pasa cuando es el cache de el resultado de una operación esto normalmente lo guardamos del lado del servidor puede ser en redis redis es lo más lo más común lo que todo el mundo conoce y utiliza
desde que hubo la polémica con Redis porque Redis empezó a transicionar un poco a no ser tan open source como uno creía yo empecé a poner el ojo en otras aplicaciones, otros servicios similares y hay muchos, me di cuenta que había muchos realmente podemos utilizar muchos servicios de caché memcache y Redis creo que son los que vienen bien para la gran mayoría de
de casos aunque hay otros que pueden ser un poco más puntuales. Entonces aquí viene la decisión, esto lo guardamos en el mismo servidor, en otro servidor, empezamos a tomar decisiones de este tipo. Aquí no hay, siento que no hay una respuesta correcta ni una que le sirva a todo el mundo, va de casos a casos. Tal vez lo que podríamos decir es que siempre y cuando estén en su propia imagen, en su propio
servicio creo que eso sería una de las grandes ventajas para para que no como mencionábamos antes no que una aplicación no estorbe al funcionamiento de la otra si lo podemos separar eso nos va a ayudar bastante entonces si definir cuál es el caché definir cuándo lo vamos a invalidar identificar por cuánto tiempo vamos a guardar este caché y luego la herramienta y dónde vamos a ejecutar esta herramienta creo que son las
preguntas que podemos hacernos porque el caché otra cosa que me gustaría mencionar es que hay, hemos estado hablando mucho sobre un ejemplo, o el caso que estamos tratando de ejemplificar es una aplicación que corre lento hay ocasiones donde eso es inevitable, hay ocasiones donde por cómo funciona nuestra aplicación es casi inevitable que un query porque tiene muchos inner joins, left joins, este resultado luego
tenemos que ir a un servicio externo esto vamos aquí y hacemos otro cálculo a veces es inevitable que tarde ojo estoy hablando de tardar 2-3 segundos un segundo que tarde un request es bastante los usuarios lo van a sentir pero en estos casos donde ya vimos que no se puede hacer mucho entonces ahí es donde ya el cachés es una solución que nos viene a ayudar muchísimo ya todo ese cálculo que hicimos
Douglas (44:21)
Sí.
Juan (44:38)
ya no tenemos que hacerlo múltiples veces sino un par de veces nada más y si a mí en lo personal como mencionaba sólo como último dato el caché me parece un tema que requiere mucho mucha dedicación porque es crucial es algo que puede o bien beneficiar y levantar tu el performance de tu aplicación o puede hacer que todo empiece a trabajar de maneras que no esperabas es puede llegar a completar agregar
complejidad a tu aplicación.
Douglas (45:09)
Me llama mucho la atención,
Me parece un poco gracioso tu respuesta de developer.
donde analizar los problemas que introduce cada posible solución. Y la realidad de las cosas es que entre más elementos le agregamos a una aplicación más compleja se va volver. Y entre más complejas una aplicación es muy probable que tenga todos estos tipos de caching que hemos mencionado y más.
porque se vuelve algo tan grande y entre más le agregamos más recursos consume, más lento se va volviendo y no queremos ese tipo de experiencia para el usuario y yo creo que lo que nos trata de transmitir es...
Cuando la aplicación está lenta hay que implementar Catching, pero no es fácil. Y yo creo que podemos probablemente a futuro Juan dedicarle un episodio entero a este tema y discutirlo poco más a profundidad. Estoy muy de acuerdo con vos. Si no sabes implementar el Catching vas a introducir más problemas de los que vas a estar resolviendo. Sin embargo, por propósito del tema que estamos tocando hoy.
Juan (46:15)
Totalmente. Sí.
Douglas (46:34)
Cuando el código está lo más óptimo posible y la configuración de tu servidor de application web server está lo más óptimo posible, toca implementar caching. Vos mencionaste usar Redis o Memcache o cualquier otro servicio, pero Redis o Memcache que son los más comunes. Lo normal es utilizarlo para algo que se llama object caching o es el resultado de un llamado a un query.
llamas un query, ese query tomó el tiempo que va a tener que tomar y dependiendo que es lo guardas en este tipo de bases de datos que funcionan en base a memoria ram que no van a ir a leer en disco duro sino que van a estar en memoria ram por ende la respuesta de esto que ya fue guardado ahí va a ser inmediata y de nuevo podemos en un episodio dedicarle más tiempo cómo funcionan que son más aquí value y no en realidad no están haciendo queries
o dependiendo de índices y por qué son rápidas, pero el punto para el propósito del tema que estamos tratando hoy es que estos resultados de queries pesados y que van a ser llamados de manera constante, ya sea el escenario de que lo que un usuario llama le beneficia a los demás o para el mismo usuario en llamados futuros, los vamos a poner en Redis o Memcache.
También tenemos algo, Juan, a nivel de servidor que se llama Page Caching, que usualmente se puede usar a nivel del web server. NGINX puede configurarse con Page Caching o puedes usar servicios como Varnish que te dan esta opción. Y es a nivel del web server, respuestas estáticas.
a un endpoint, ya sea contenido estático, HTML, o puede ser la respuesta de un API, queda guardado en page caching, dependiendo del servicio que usted es, puede ser como disco duro, o puede ser otro tipo de memoria a nivel de servidor.
Pero es una respuesta que ya va a estar lista para ser servida de manera rápida e inmediata en el servidor sin tener que ir a hacer el procesamiento a la base de datos o sin tener que ir a hacer el procesamiento al application server. Por ejemplo, si usas page caching para cachar respuestas de un API, NGINX en lugar de mandar.
ese llamado al application server, sea Golan, sea PHP, sea Python o lo que sea y por consecuencia el application server mandar ese llamado a la base de datos eso no ocurre, NGINX inmediatamente lo agarra de page caching y lo sirve, verdad, si usáramos de nuevo NGINX también están estos otros servicios como Varnish o en...
en CMS como WordPress hay diferentes plugins que pueden ayudar a hacer esto, otro tema, no usar un plugin sin entenderlo bien y muchas veces un plugin va a introducir más problemas de lo que resuelve, pero el punto es caching es...
necesario cuando tenemos una aplicación donde el tráfico empieza a ser más allá que un par de personas al día, donde el tráfico empieza a ser más allá que sólo un par de recues cada cierto tiempo y por cuánto tiempo guardamos el cash in también es muy importante. dejemos para un episodio futuro Juan.
los detalles de su implementación, sin embargo, creo que vos y yo coincidimos en que si todo está bien y la aplicación sigue lenta, tenemos que explorar opciones de caching.
Juan (50:25)
totalmente si si definitivamente el caché es algo que deberíamos manejar deberíamos manejar todos entenderlo saber en qué momento se utiliza podríamos decir que siempre se debe utilizar pero a veces digamos que nuestro producto está empezando tal vez podemos omitirlo hasta que sea necesario entonces sí es importante conocerlo así que totalmente me gustaría volver a tocar este tema en otro vídeo
Bien, ya para ir cerrando Douglas, creo que ya hemos tocado muchos temas que pueden ir viendo las personas para el momento que les toque tratar de identificar qué pasa con su aplicación. Así que me gustaría ir cerrando con unos cuantos consejos, tal vez rápidos, de mi lado como developer y tal vez podría dar uno dos más de tu lado como...
DevOps y administrador de los servidores y operations. Tenés muchos títulos. Ok, de mi lado yo mencionaría que si la aplicación está lenta, lo primero es comparar cómo se comporta en mi computadora versus el servidor. Pero ojo, aquí tiene truco porque nuestra computadora siempre va a comportarse diferente, así que es necesario tratar de replicar lo más que podamos el ambiente.
limitar los recursos que le vamos a otorgar a nuestro servicio, a nuestra aplicación y tratar de limitarlo a como normalmente estaría en el servidor. Otro consejo que les puedo dar es empezar a aislar pequeñas partes del código. Si nuestro código hace llamados a la base de datos, hace llamados a APIs externos, podemos hacer mocks de estos servicios internos para revisar si
y
el cuello de botella no está en este request externo que estamos haciendo desde nuestra aplicación y por último también me gustaría mencionarles que al menos en Go es bastante fácil podemos utilizar concurrencia si nuestro proceso en un determinado endpoint necesita hacer múltiples cosas a la vez podemos ir haciendo estas cosas en paralelo aunque no es paralelo
para ir acortando tiempos, en vez de esperar a que la primera tarea termine y luego la segunda y luego la tercera podemos ir haciendo las tres casi a la vez y así acortamos tiempo, entonces en Go es bastante fácil por su concurrencia pero en cualquier otro lenguaje vas a poder hacerlo también en NodeJS tenes las Provenzas, en Java supongo que los Threads y así en cada lenguaje vamos a poder hacerlo de una manera diferente pero la idea es acortar tiempos donde se puede
y bien, de mi parte, esos serían los consejos más básicos que te podría dar para que puedas identificar dónde está fallando tu aplicación si está muy lenta. Douglas, no sé si tenés algún otro consejo tal vez medio rápido, medio... no sé, que tengas por ahí.
Douglas (53:39)
Fijate
Juan, que en la parte de infraestructura falta bastante tela que cortar. Podemos de nuevo llevar esto a una discusión más detallada a futuro, pero luego de haber visto las cosas que ya mencionamos, de nuevo, lo que ya mencionamos sería como yo iniciaría. Código, configuración de servidores, ver qué falta para mejorar el performance y dentro de lo que falta...
puede ser que te falten recursos. Está bien configurado el web server según la capacidad que tiene tu servidor, sea VM, sea servidor físico, sea contenedor. Y ya le agregaste caching y aún así está lento. Entonces, es muy probable que no estás cuantificando los recursos correctos para tu aplicación.
puede que te falte más CPU porque estás corriendo procesos intensos de lectura y escritura en disco. Y lectura y escritura en disco aparte de un buen disco, asegúrate de usar SSD. Si vas a hacerlo bastante seguido, vas a necesitar bastante CPU. Puede que necesites más memoria. Si estás cargando en memoria queries pesados o archivos pesados.
en tu base de datos muchas veces hay configuraciones en MariaDB o MySQL donde estos queries que tienen bastante joins crean tablas temporales y se puede hacer que MySQL escriba estas tablas temporales en file systems que son en memoria RAM en lugar de file systems que son en disco duro y eso va a hacer que lo haga de manera mucho más rápida obviamente eso va a...
consumir más memoria en lugar de más discos, por ende hay que darle más memoria y como dijiste cuando hablaste de Catching, si la vida fuera tan fácil, pero al final son cosas a mejorar, veces ver que tengo suficiente espacio en disco, muchas veces no me doy cuenta que tengo poco espacio en disco y por ende el sistema operativo se vuelve más lento, si estamos trabajando en la nube, ver que tenemos la instancia, el tipo de instancia correcta.
Por ejemplo, en AWS están este tipo de instancias que son las T2 o T3 que trabajan con un sistema de créditos para CPU y es bien interesante porque te da cierto uso para CPU y vas acumulando puntos, por así decirlo, mientras no uses tanto CPU. Pero cuando empezás a necesitar CPU, lo consumís de esos créditos, pero si tu aplicación o tu proceso se pasa...
dependiendo qué instancia tenés o topa y no te da más CPU o te da más CPU pero el performance no hace mejor y te va a cargar más dinero por ello, verdad? entonces a veces ese tipo de cosas o muchas veces que es lo más recomendable y siempre que puedan
yo lo recomiendo hacerlo desde el inicio si es posible, separar la aplicación, las diferentes capas de la aplicación en instancias distintas. La base de datos en un servidor por aparte, el application web server en servidores o instancias por aparte, si se tiene un tier de memcache que esté por aparte. Separarlo de esa manera, le incrementamos recursos a la capa o al layer que lo necesita únicamente, si el problema son recursos.
Y nos permite facilitar el mantenimiento porque no necesitamos afectar todo al momento de mantenimientos. eso por el momento Juan de nuevo, en la parte de infraestructura hay bastante tela que cortar, pero yo creo que la intención aquí para las personas que tienen poca experiencia...
debugging aplicaciones y sobre todo cosas del rendimiento o el performance de un sitio o una aplicación es la mentalidad con la cual acercarse como que esa lista de paso de qué ver primero y de nuevo insisto voy a insistir una vez más primero vayan a ver que el código sea óptimo y que la configuración de la aplicación sea la más óptima posible entonces creo que me extendí bastante
Y aun así siento que me faltó mucho por transmitir, pero esas serían como las recomendaciones de parte de infraestructura que pudiera dar.
Juan (58:16)
Si, si concuerdo en que falta mucho, verdad es que estamos hablando de todo lo que las optimizaciones que podemos hacerle. También por el lado de la base de datos hay todo un mundo que se puede explorar por ahí. Pero bien, hemos tratado dar algunos unos que otro consejo. Esperamos que tal vez esto le suelte alguna idea o los incite a investigar un poco más de estos temas que hemos hablado. Y sí, definitivamente vamos a tratar de hacer otros episodios.
episodios donde podamos hablar un poco más de todo esto.
Douglas (58:52)
Bueno
perfecto Juan, creo que por este episodio ha sido suficiente, espero que quienes nos ven y nos escuchan hayan recibido valor de esta conversación. Juan me despido de vos, hasta el próximo episodio.
Juan (59:09)
Igual nos vemos Douglas, nos vemos todos, nos vemos la próxima.