Detectar los problemas de rendimiento y que tu web Drupal cargue rápido

Hola, ¿qué tal? Aquí otra semana más en Drupalízate. Antes de empezar, quiero comentar, porque no sé si has leído mi última newsletter en LinkedIn, que fue este pasado lunes. En ella comenté que estaba pensando dejar de publicar contenido semanalmente. Y bueno, lo confirmo aquí, también lo confirmaré en la newsletter del lunes que viene. Pero básicamente es que no me da la vida para todo, así que voy a dejar de publicar contenido. No te preocupes, voy a seguir publicándolo, pero no lo publicaré semanalmente. La idea es publicar cada dos semanas y interclarar lo que es la newsletter con el podcast. Porque hasta ahora estaba publicando la newsletter el lunes y el podcast el viernes, cada semana. Y ahora mismo, por temas de trabajo, entre otras cosas, porque estamos a las puertas de navidad y varios clientes busquen las cosas antes de que empiecen vacaciones de navidad, así que dan un poco... Bueno, tengo más trabajo de lo que debería en teoría. Eso primero. Después también me gustaría tener tiempo para mí, para el disfrute mío, y después también para side projects míos, entre los cuales está el generar contenidos. Así que básicamente no me da la vida para todo. Y por ejemplo, hoy mismo estoy grabando esto, que lo voy a publicar tal cual acabé de grabar, porque no he tenido más tiempo. Es que no lo tengo ni preparado. Mi idea es publicar cada dos semanas, tener un poco más de aire para prepararme las cosas, o es la intención al menos. Y nada, básicamente que lo sepas que a partir de ahora voy a empezar a publicar cada dos semanas. No te asustes, ya semana que viene no hay episodio. Lo habrá de aquí dos semanas, así que tranquilo. Bueno, he dicho todo esto. Y según el título que ya has visto en el podcast share. Este episodio lo quiero hablar sobre cómo detectar problemas de rendimiento en webs en tu pal y cómo hacer que cargue más rápido. Seguramente no será a nivel básico, sino que como siempre me dieron un poco para ramas y acababa siendo un nivel medio avanzado. Voy a explicar cómo lo hago yo, cómo trabajo yo, qué herramientas uso yo. No significa que sean las mejores, significa que son las que conozco yo y las que he usado y las que me funcionan a mí. Y dejar esto claro, porque tampoco... soy experto, pero porque yo trabajo con herramientas de estas, no porque me las conozca todas. Dicho todo esto, imaginemos que lo que me llega es un cliente que tiene un portal web más o menos mediano grande con muchos tipos de contenido, muchas taxonomías, que tiene código custom, o sea módulos custom, que tiene el tema custom y que también tiene muchos, por decir algo, hasta unos 100 módulos contribuidos. Que también me encuentra proyectos con muchos módulos contribuidos. Y viene con la queja de que hay URL de mi web que tardan 3 segundos, 4, 5 o 2 segundos y medio. O sea, depende de... esto también tened en cuenta, depende del cliente. Digamos, es inviable tener URL que traden más de 1 segundo, segundo y medio o 2 segundos. Eso ya es la web valenta. En otros clientes, ah, que tardan 3 o 4 segundos, bueno, es aceptable. Pero es que tengo esta URL, en concreto una única página, que aquí me tarda 30. O sea, son dos casuísticas distintas. A todo esto, primero lo que se le veía es limitar, o sea, acordar con cliente qué es lo que estamos buscando. Que todas las páginas tengan un tiempo de carga mínimo, perdón, mínimo, máximo de, por decir algo, 2 segundos. Ver si esto es factible o no, pues el tipo de proyecto qué es y cómo está montado. Que en algunos casos no es factible tener tiempo de carga tan bajo, dependiendo del contenido que estás mostrando y la cantidad de contenido que estás gestionando. En otros sí que es factible, pero asumiendo un coste, tanto a nivel del servidor como a nivel de refactorizar código, que cliente básicamente lo ve inviable a nivel de costes. Pero bueno, lo primero sería esto, aclarar si lo que quieres para todas las páginas es un tiempo máximo de, digamos, muy bajo, que en teoría es lo bueno para el SEO, de esto un segundo, dos segundos, no mucho más. A poder ser que sea menos de un segundo el tiempo de carga. Y la otra es que tenemos urls puntuales que nos van de mar y que son varios segundos, cinco, seis, siete. Yo he estado con urls que están a más de 20 segundos de tiempo de carga. Y en algunas que, depende del caso, si tenían muchas visitas, no muchas visitas, algunas visitas en esas páginas, la página dejaba de responder porque pasaba de los 30 segundos de tiempo de PHP de ejecución. Así que, como digo, depende del caso. Lo primero, limitar bien qué es lo que está buscando el cliente con lo que según él entiende cómo que la web es lenta. Lo segundo sería limitar o, digamos, replicar en qué casos está pasando eso que el cliente se queja que va lento. Me explico, puede ser como digo que sea una única url. Ese caso es el más simple. Por ejemplo, tenemos un... lo digo como ejemplo porque me he encontrado varios. El más visual es que hay una única página de quiénes somos, dónde estamos, que tenemos un mapa y ahí se están pintando los puntitos del mapa de las franquicias, en este caso de cliente. Si tienes unas decenas o unos cientos, puede ser medio factible mostrarlas todas de golpe. Pero en el momento en que tienes unos cuantos miles, puede ser de que vaya lento de narices y que tarde, como comentaba, unos 20 segundos en cargar la página. En ese caso, está claro, es una única url y el problema, sin hacer mucho debug, tiene toda la pinta que es cosa del mapa, de que está intentando cargar miles de nodos al mismo tiempo y pintando información al mismo tiempo de todo, cosa que no debería montarse así. Seguramente debería mostrar solo los puntos y después puede Ajax, en el momento de hacer clic, mostrar un popup solo de ese ítem. O montártelo con una cosa que no se llama jseql, por ejemplo usando Elasticsearch, similar a lo que hice yo con el proyecto de Babiso, que ya lo comenté en episodios anteriores. Pero bueno, en el caso tenemos una url que va mal. Pues es el caso más simple porque, digamos, está muy limitado y es muy fácilmente replicable, de que esto en local también ha de ir lento solo en esa url. Todo el caso contrario, tenemos que toda la web en general valenta. Esto puede ser lo lógico que os había pensado al principio, tenemos problemas con el servidor, o la opción de php es muy vieja, o tenemos que el servidor no tiene suficiente CPU o RAM y tiene cuerdos de botella, en ese sentido, o tenemos muchas visitas y el cuerdos de botella es jseql y hace que toda la web en general vaya lenta, o que después si nos cosa el servidor, bueno, también aquí en medio estoy descartando de que, por decir algo, se ha probado ya a poner memcache o redis para moverla a cache de mysql a nivel del servidor y eso no arregla el problema, se ha probado también a meter una cdn por el medio y eso tampoco arregla el problema, si se descarta que no es ni servidor, ni cdn, ni memcache, ni nada de esto, nos queda al final de es problema de código. Hay algo en el código que hace que todas las páginas de esta web vayan lentas. Ejemplos que me he encontrado yo, los más típicos son los menús, tenemos algo en los menús, en el menú de cabecera o en el menú de footer, que hacen cosas raras, normalmente no son menús por defecto de ropa, sino que son views que listan cosas de forma automática, normalmente que son views que no tienen cache, normalmente que están listando contenidos o con muchos joints, muchas relaciones entre ellos, o sea, son views, son consultas a base de datos, digamos, bastante complejas y bastante lentas de ejecutarse, con lo cual están haciendo bloqueantes en base de datos y además, como digo, son lentas de ejecutarse, o que directamente son menús que se generan desde código hecho a medida, que están haciendo llamadas a servicios externos, a una API por ejemplo, y que por ejemplo no se está cacheando, con lo cual cualquier solicitud a esa url, a cualquier url de la web, por debajo está obligando a hacer otra petición a una url de una API, que por decir algo, si esa url consume 50 milisegundos de la petición contra la API, son 50 milisegundos más que estás sumando a todas las urls de tu web, así que lo lógico es que haya cacheado el resultado, y que sólo trae 50 milisegundos, estoy poniendo un ejemplo de 50, cuando pueden ser 150, 200 o 2 milisegundos, depende de cómo esté montada la API y dónde estás haciendo las llamadas, pero es esto, tienes un tiempo que se suma. Pues depende de cómo esté montado, sería lo más lógico es hacer la llamada una única vez, una primera vez, se cachea la respuesta, Drupal en la cache lo mantiene, y lo que estás mostrando al usuario de tu web es la cache, con lo cual te ahorras esas posteriores llamadas a una API o a un servicio externo, como puede ser un Solar, o un Elasticsearch, o lo que sea de donde coja los datos. Como digo, esos son los casos digamos los que más me he encontrado, también puede ser de que no afecte a todas las páginas por igual, sino que afecte solo a una sección de la web, sea una sección grande o una sección pequeña, por ejemplo el listado de taxonomías, o el listado del blog, sólo afecta a los nodos de tipo artículo del blog, no afecta a la parte del e-commerce por ejemplo, o al revés, sólo afecta a las páginas de producto. A partir de aquí es investigar de qué hay de distinto, por ejemplo en las páginas de producto, para que aquí vaya más lento que en las páginas de artículos. Pues en las páginas de producto tenemos un listado de relacionados por categorías, por decir algo, y ahí no está cacheados, o estamos mostrando por 50 productos relacionados, en vez de tener un paginador, de ir mostrando más, de cuatro en cuatro. Quizás el problema viene de aquí, o sea, ya no es ni código, es configuración, y es muy fácil de cambiar. Pero es detectar las casuísticas, en qué condiciones se cumple esto, replicarlo, y también comprobar que esto en local sigue pasando, que lo que te va lento en producción, también te va lento en entorno de desarrollo o en entorno local. Vale, aquí todo es muy bonito porque te da las soluciones, porque te he dicho, puede ser que sea el menú, puede ser que sea el footer, puede ser que sea un bloque de relacionados, claro, eso es porque yo ya me lo he encontrado y he encontrado soluciones para algunos proyectos de clientes. Pero, digamos, la parte divertida de esto, o divertida para mí, no para el cliente, es saber encontrar esto, porque cada proyecto es un mundo, y no tiene por qué ser las cosas que te he dicho yo, puede ser que tengas otra casuística distinta en tu proyecto. Así que a mí me contratan justamente para, digamos, encontrar el error base, detectar qué está pasando y por qué, y a partir de aquí después dar soluciones, el problema es que esta vista está mal configurada, o estamos haciendo esto de esta forma, sería mejor hacerla de esta otra forma, o el código está hecho de esta forma por X motivo, creo, normalmente son webs que no he hecho yo, tienen que hacer muchas suposiciones, pues si el código está hecho de esta forma sería mucho mejor por rendimiento hacerlo de esta otra. Pero esto tiene esta implicación que se debe tener en cuenta, que no sé si para vuestro proyecto es factible o no. Por ejemplo, que tengamos el listado de productos relacionados, que lo estemos cachando por página, por ejemplo, o que lo estemos cachando por tiempo. Que el listado de relacionados, durante una hora, sea el mismo para todos los productos de la misma categoría, por ponerte un ejemplo, que se ha hecho en algún proyecto. En algún caso puede ser factible de que siempre estés viendo los mismos, en otro caso no puede ser factible porque se quiere incentivar de que siempre estén viendo productos distintos. Esto, como digo, depende del tipo de proyecto, depende del tipo de cliente. Vale, ¿cómo hago yo para encontrar el problema de base? ¿O para investigar cuál puede ser el problema? Primero de todo sería, si un caso, probar con módulos en Drupal. Digamos el módulo DEVEL o el módulo Xproof, ah perdón, Xproof, me he liado, el módulo Web Profiler, que son módulos en Drupal, que te dan, digamos, estadísticas de por ejemplo qué queries de main.cql se están ejecutando en nuestras páginas, o los tiempos de carga, o los tiempos de randomizado del HTML, digamos que te dan pistas de qué parte puede ser la más lenta, pero digamos que es a grosso modo, ¿vale? El Web Profiler sí que te puede dar más pistas, no, te va a dar más pistas que lo que es el módulo DEVEL, pero aún así en muchas ocasiones se puede quedar corto. Digamos que sirve para tener una primera impresión, y en algunos casos te puedes a partir de aquí encontrar una solución o encontrar el problema, como decía antes, pero en muchos otros se queda corto y te hace falta más información. Aquí es donde entran herramientas como Xproof, por ejemplo, que hace mucho que ya no la uso, pero en su día la usaba bastante. Y después está por ejemplo Blackfire, que es el que dejé de usar Xproof para pasar a usar Blackfire, Blackfide en español, de que básicamente es un profiler, o sea, como explico, te permite mostrar un árbol de por dónde están pasando los procesos de PHP, o sea, tú cuando cargas una página PHP calcula cosas, pues te dice el nombre de la función y te dice que esta función llama a esta otra función y que esta hija llama a otra hija, y te va diciendo por dónde está pasando el código. Con lo cual tú puedes ver qué funciones se han llamado, cuántas veces se han llamado, cuánto tiempo han consumido y cuántas CPU RAM han consumido. Eso es bueno, por ejemplo, para ver qué funciones consumen más RAM del servidor, si es que el problema es que el servidor se está quedando sin RAM, por ejemplo, o qué funciones se llaman más veces y qué más tiempo consumen. Por ejemplo, que estamos haciendo un node de LOAD o un node de render, pues cuatro o cinco veces seguidas, cosa que por rendimiento no tiene mucha lógica de por qué. Al final te pueden dar pistas de qué está pasando. Como digo, yo en su día usaba Xproof, lo digo de memoria, es una cosa que desarrollo en Facebook para análisis de PHP. Pero bueno, o se dejó de tener soporte o por lo que fuera, ya no me acuerdo muy bien, yo empecé a usar el Blackfire, también porque la interfaz es mucho mejor. Me suena desde que hace poco tiempo que el Blackfire ya no tiene la opción gratuita para desarrolladores, que antes sí que la tenían cuando yo lo usaba. Igualmente, yo recomiendo, lo puedes pagar un mes, intentas optimizar todo lo que es la web durante ese mes y después ya dejaste de pagarlo y ya no lo usas más. Pero si lo que te interesa es obtener datos, hacer pruebas, pues con un mes tienes más que suficiente. Yo ya no lo uso porque estoy usando desde hace bastante tiempo también, la verdad, New Relic. Y de las tres es la que más me gusta, la que mejor interfaz tiene y sobre todo, desde mi punto de vista, la que se puede activar en producción y te da datos reales de producción. Eso significa que al tener esto en producción activado, estás viendo en tiempo real, y también puedes compararlo con lo de hace una semana, por ejemplo, ver que al cargar cierto tipo de páginas, o sea, cuando tus files van a X páginas, estas son las más lentas. O que quizá haya una URL que tu cliente ha detectado que esa es muy lenta. Sí, pero es que los usuarios que navegan por la web a esa URL apenas acceden. Cuando acceden siempre van al blog. Quizás más interesante optimizar el rendimiento del blog que no dedicar tiempo a una página de quiénes somos, que ahí entran cuatro personas. Depende del caso y depende del proyecto. A menos con estadísticas, con datos en la mano, puedes tomar mejores decisiones. Por eso a mí me gusta mucho New Relic en ese sentido. Aparte, hace lo mismo que hace Blackfire, por ejemplo, que te permite decirte los nombres de funciones, cuáles están consumiendo más tiempo, o cuáles están consumiendo más memoria RAM. Te opinta en gráficos, digamos, visualmente atractivos, con lo cual estás viendo el tiempo que consume MySQL, el tiempo que consume PHP. Lo que te permite también ver si el problema lo tienes en MySQL, que puede ser que tengas las caches de MySQL. Te permite ver si el tiempo que consume también sistemas como Memcache, si es que lo tienes activo. Al final te permite comparar si lo lento es PHP, si lo lento es MySQL, si lo lento son las caches que tienes en otros sistemas como pueden ser Memcache. Te dice los tiempos, si es que estás usando conexiones externas, los tiempos a APIs externas. Y también puedes ver si se están haciendo demasiadas llamadas externas que se pueden estar cacheados, con lo cual te ahorrarías tiempo y conexión y transferencia. Así que también lo recomiendo solo por eso. Y además, digamos, la gota que colmo al vaso y el motivo por el que estoy usando yo New Relic es que tiene integración con Drupal. Eso significa que cuando el servidor PHP está mandando datos en New Relic, New Relic está analizando de que, ah, esto es un Drupal. Ah, vale, pues ya tienes una página de estadísticas que te dice las views, los listados de Drupal, cuáles son los más lentos, con el nombre de la vista, tal cual. También te dice los módulos de Drupal que son los lentos que tienen más tiempo, que están consumiendo más en el servidor. Con lo cual, no siempre la cierta, ahora comentaré por qué, pero básicamente sí que te da unas guías bastante claras de por dónde puede venir el problema. Sobre todo, sin que te haga falta contratar, digamos, un programador para que sepa leer New Relic, de forma bastante simple estás viendo de, ah, vale, el problema parece ser de que tengo estas dos views que me están consumiendo más de la mitad del tiempo de carga. Vale, esta view se llama, mmm, menú header. Ah, pues seguramente sea la vista que se está mostrando en el menú. Pues quizá el problema que tengo es que esa vista, que está en todas las páginas porque está en el menú, tiene un problema de que está algo mal allí. Vale, o sea, te dan muchos indicativos y a mí me soluciona mucho la vida. Aún así, no siempre te lo da, digamos, todo, em, mascado, o sea, no te lo da todo hecho. Por ejemplo, te puede decir de que el problema es uno de los módulos del COE, como puede ser, yo qué sé, el módulo de los nodos o de las taxonomías o de las vistas, cuando en verdad el problema no es ese, sino que el problema es una mala configuración que se tiene que investigar cuál es. O puede ser que tengas código hecho a medida que está llamando a funciones de módulos contribuidos o módulos del COE y lo que New Relic te detecta es que lo que se pierde más tiempo es haciendo, por ejemplo, en la renderización del nodo, en los viewmodes de los nodos. Cuando en verdad el problema es que hay código custom que está haciendo, forzando esas, esas renderizaciones de los viewmodes y el problema arreglado es que el código custom no haga eso, o sea, que lo haga una vez, pero no cuatro o cinco seguidas. Así que, como digo, te sirve para tener la idea de qué está pasando, pero aún así hace falta que alguien interprete los datos. No siempre, en la mayoría de casos al menos, no siempre es, digamos, claro, uno a uno de, ah, vale, abro el panel de control de New Relic y ya me dice cuál es el problema. No, hace falta que alguien interprete un poco los datos. Aún así, los datos que te da en parte son bastante interpretables por alguien que no es técnico. Con técnico me refiero a alguien que no es súper experto. ¿Y qué más comentar de esto? Vale, una cosa que no he comentado es, como te decía, el dar palos de ciego y hacer cosas manualmente. En algunos casos, cuando vas hiper perdido y no sabes, es que en mi caso con New Relic o con herramientas de este tipo, perdón, eso no lo he comentado, son herramientas tipo APM, Application Performance Monitor, que básicamente se conecta a PHP y en tiempo de ejecución está diciendo, enviando datos de qué funciones de PHP están haciendo y qué consultas mySQL, o sea, se envían estadísticas a nivel de ejecución de PHP. Se llaman APMs, ¿vale? Todo lo que digo de New Relic me está refiriendo al APM de New Relic, porque New Relic tiene muchas otras cosas que no entran en lo que digo de este episodio, que también uso algunas, como son infraestructura, pero que en este caso me refiero únicamente, exclusivamente, al APM. Vale, volviendo al caso, puede ser que, o porque no tienes herramientas de estas, o no las sabes usar, o no las quieres usar, o las tienes, pero no entiendes los datos que te devuelven, digamos que vas perdidísimo y sigues sin saber qué está pasando y cuál es el motivo de que te vaya lenta la web. Pues básicamente lo que te queda es, como digo, dar palos de ciego. Lo que he tenido que hacer yo en algún caso, cuando he ido muy perdido, es ir rompiendo la web. Básicamente, cuando empiezo por los modos custom, en vez de los contribuidos, o por los temas custom, por ejemplo, elimino, o mejor dicho, desactivo, y pongo un tema de contribuido, o sea, un tema del code, de Drupal, visualmente la web queda rota. Por supuesto, lo hago en desarrollo, o sea, nunca en producción. Esto no se toca nunca en producción. Y comprobo que si al cambiar el tema, los premios de rendimiento en gran parte se arreglan o no. Si no es así, voy siguiendo con módulos hechos a medida. Voy desactivando los módulos, o sea, desinstalándolos, y viendo de si la página queda a problemas, o la página, o la sección, o lo que hemos dicho al principio de todo, que hemos detectado que es replicable en estas partes de la web, si todo eso se va arreglando, hasta que encuentro el problema. Si después de desactivar todo lo que es temas custom y módulos custom, sigue sin ir bien, empiezo con los módulos contribuidos. Lo mismo, ir desinstalándolos. Como digo, te vas a ir rompiendo la web. El tema es saber que ir desinstalándolo sin que la web quede totalmente rota, sino que siga funcionando visualmente mal, pero que siga funcionando y calculando cosas, o sea, realizando la HTML. Al final, seguramente habrá un módulo que al desinstalarlo verás de, ah, aquí se nota que va mucho más fluido. Vale, aquí es analizar si ese módulo ha estado en uno en el proyecto, cuál alternativa puede haber para dejar de usarlo, o qué configuración puede ser de que esté mal. Esto solo me ha hecho falta, en algún caso en concreto, con módulos custom que ni siquiera con New Relic podía llegar a ver, o sea, no me daba suficiente información para ver que era culpa de ese módulo. Una vez ya sé que es de ese módulo, lo que toca es analizar qué parte del código de ese módulo se está usando en esa página, leer el código, entenderlo, y pensar qué está pasando para que esto esté funcionando tan mal de rendimiento. Qué puede ser de que no esté pensado para un escalamiento de cuando tengamos unas cuantas visitas concurrentes, que no se ha pensado este módulo para gestionar cachés, por ejemplo, que no está pensado el módulo para, yo qué sé, está más pensado para MySQL y estamos usando Postgres nosotros. Aquí viene lo que es investigar y hace falta ser simple, ¿vale? Para eso. Pero como digo, es ir dando palos decisivos. Y a todo esto lo pongo como ejemplo porque en muchos casos los clientes que me llegan a mí, algunos, me piden de, no, no, es que quiero un presupuesto cerrado, ¿cuánto me cobras por arreglar la web? Y son, es que no te puedo dar un presupuesto cerrado, o sea, te puedo dar una bolsa de horas y a partir de aquí vamos viendo, porque es una web que yo no he hecho, primero me la tengo que instalar, analizar, ver cómo está hecha, y como he dicho, usar estas herramientas como New Relic y otras para ver qué está pasando por detrás. A partir de aquí, si encuentro cuáles son los problemas, pues puede que encuentre solo algunos y no todos, ver primero qué coste tienen para allí, porque puede ser que sean, reacetar la media web, con lo cual el coste puede ser muy elevado y cliente final dirá, no, no, pues mejor se queda así. O mejor hacemos X cosas para mejorar un poco, pero no hace falta que esté, digamos, de la mejor forma posible 100%, sino que me vale con un 50%, porque me salda mucho más rato hacer un pequeño patch, una pequeña solución, más que arreglar el problema de base. Por eso que al final a mí me cuesta mucho dar un peso puesto cerrado, básicamente porque es analizar código de otra gente, o sea, una web que ha hecho otra gente, analizar qué está pasando, dar soluciones, y en base a las soluciones y la casuística del proyecto y del cliente, decidir si es viable o no hacer esas soluciones, implementar esas soluciones. En varios casos es inviable, ya sea porque por el tema de que se quieren mostrar productos o páginas en tiempo real, no se puede cachear de una forma, digamos, más, a no me sale la palabra, o sea, durante más tiempo, tiene que estar, digamos, como máximo 10 minutos o menos de 10 minutos, o directamente sin caché en alguna parte de la web, porque como digo, por el tipo de proyecto tiene que ser en lo máximo de tiempo real posible. Aunque buen motivo que sea, a cliente no le vale, hay un módulo que sí o sí hemos de usar por casuísticas del proyecto, y no le vale que ese módulo se deje de usar. Por decir algo, lo que era antes en Drupal 7 era Panels, que aún corta de las venas por temas de rendimiento, si toda la web está montada con Panels y la decisión es dejar de usar Panels, básicamente significa rehacer la web entera, con lo cual el presupuesto es rehacer la web entera. Y aparte que le quita la flexibilidad al usuario que está editando la web, porque Panels, una de las pocas cosas buenas que tenía, era de que era muy flexible desde el punto de vista de que era todo configuración. La parte mala, que de rendimiento, era una patada. Pero bueno, esto, que al final se ha de hablar con cliente y ver qué cosas pueden hacer y cuáles no. Normalmente esto es una bolsa de horas. Se contó una bolsa de horas, se ve hasta qué punto llegamos y qué cosas encontramos, y a partir de aquí se puede encontrar otra bolsa de horas, o si ha dado tiempo, dentro de la primera, para intentar arreglar las cosas que se han encontrado, si es que son, como digo, viables desde el punto de vista del proyecto. Y nada más, si queréis os comento así casuísticas de cosas que me he encontrado, o sea, de proyectos reales, cosas mal hechas, que quizás en vuestro proyecto puede ser, digamos, un problema de base. Como he comentado, me he encontrado algunos proyectos con tema de mapas, que es lo común de, tengo una web real y donde hay un mapa. Vale, posiblemente es que estás mostrando muchos puntos en el mapa con toda la información. Se tiene que hacer el mapa desde cero, a poder ser que no use MySQL, y si tiene que usar MySQL, lo suyo sería que mostrase solo los puntos y después, al hacer clic en el punto, que te cargue, vía Ajax, por ejemplo, la información del punto. Pues el título, las imágenes, y lo que sea. No tiene lógica, cargas mil puntos de golpe, con toda su información, títulos, imágenes, textos, todo de golpe. No tiene ningún sentido. Aún así, me he encontrado webs que están hechas de esta forma. Después me he encontrado menús que están haciendo uso de las vistas para listar taxonomías y listar nodos como ahijados de taxonomías, con ciertos parámetros y aparte sin cachés de las vistas, con lo cual el menú de cabecera afectaba toda la web y hacía que todo fuera lento. Y no una web, sino algunas me he encontrado así. Después me he encontrado, por ejemplo, menús, ya sea de cabecera o del footer, que venían de APIs externas, porque básicamente el cliente tiene varias webs, y todas las webs tienen que tener los mismos enlaces de cabecera para llevar a la página principal, o sea, a la web principal que tiene esta gente. Pues si no está bien implementado el código que te genera el menú este, que lo suele ser tener un caché mínimo de unas cuantas horas, pues esto, que al final está haciendo demasiadas llamadas externas, con lo cual al final la web en general va más lenta. Me lo he encontrado también en unas cuantas ocasiones de esto. Después, cosas raras, pues por ejemplo que al renderizar una vista en Drupal, estás vaciando todas las cachés de toda la web. Dicho de esta forma, cuando un usuario entra en una URL y esa URL está pintando una vista en concreto, esa vista por código alguien decidió de que, uy no, si no vaciamos cachés no muestro los resultados que quiere el cliente, pues hacemos de que la vista va a ser toda la cachés. Pues, problema, que cuando entra por ejemplo un bot de Google a esa URL, estás vaciando todas las cachés. Problema con eso, que hay una web muy grande, que además, al vaciar todas las cachés, hay un tiempo de inactividad, porque hay páginas que se quedaban caídas unos segundos de esa web. Así que, también cuidado con lo de vaciar cachés desde código, sobre todo cuando es código custom, y no sabes por qué. O sea, por qué estás vaciando todas las cachés cuando se está ejecutando una vista con una idea de vista en concreto. O sea, no tiene ningún sentido. A menos no desde mi punto de vista. Lo que se hizo fue desactivar eso y que los resultados de las vistas no usaran las cachés, ni el ViewMode del nodo que se pintaba, ni tampoco de la misma vista. Que al final, básicamente, era un problema de configuración. Después, otros que me he encontrado, pues por ejemplo, en el menú de una web, habían los típicos enlaces de quienes somos, dónde estamos, y a uno más. Y el interesante que es uno de contacto, que te lleva a la página de un formulario de contacto. Pues, tener esos enlaces arriba, más un módulo contribuido que digamos que lo que hace es que por siabascript, cada persona que entra en la web, digamos que precarga todos los enlaces visibles de la pantalla del usuario, entre los cuales están los del menú porque el menú siempre está visible arriba, significa de que cualquier usuario en cualquier URL está forzando a cargar todos los enlaces del menú. El problema con esto, que como digo, teníamos la página de contacto, teníamos un formulario, un webform, y además, teníamos un módulo contribuido que es el de captcha, que hace que en el formulario donde salga la captcha, y en el de contacto salgase captcha, se invaliden las cachés. Con lo cual, teníamos una caché invalidad en una página que estábamos cargando siempre. Digamos que la solución fue, se desactiva el módulo contribuido que te está cargando URL por debajo, porque cuando tienes unos cuantos usuarios concurrentes en la web, estás haciendo demasiadas solicitudes. Por ejemplo, si tienes 20 enlaces en el menú, porque al final son los visibles y los del subitem del menú. O sea, son los enlaces que están, digamos, de la pantalla del usuario para arriba. Si están disponibles se seguían cargando, por ese caso también. O sea, la solución fue, si se activa el módulo que te cargan los enlaces, porque no tiene ningún sentido que si tienes 100 usuarios que están cargando en la web, en vez de cargar 100 URL, estás cargando 100 URL por 20 enlaces, estás cargando esto. O sea, ¿2000 enlaces? No, no tiene ningún sentido. Y aparte de los 2000 enlaces, uno de cada 20 es una página sin cachés, con cachés invalidadas, de un formulario de webform que también esa página en sí ya iba lenta. Así que era uno de los motivos por los que el servidor estaba sobredimensionado y tenía un coste bastante elevado para el cliente. Cuando se quitó eso, el servidor se pudo reducir por 4 en potencia, con lo cual tuvo un ahorro considerable en producción. Otros casos que me he encontrado, por ejemplo, hablando de formularios, pues formularios incrustados en páginas. Lo mismo, si tenemos el modulabocaptcha que invalida cachés de la página donde está el formulario, si tenemos un formulario en todas las páginas, por ejemplo, en todos los artículos del blog, tenemos un formulario de comentarios, o tenemos un formulario de contacto en el footer de la web, en todos los artículos del blog, pues puede ser de que estés invalidando caché para todas las páginas del blog. Imagínate un idealista, yo no he trabajado para idealista, pero imagínate que es una inmobiliaria, y cada página, todas las propiedades inmobiliarias que salgan allí, tiene un formulario de contacto. Si no vas con cuidado, estás invalidando caché de todas las urls que sean de esas propiedades inmobiliarias. O sea, el blog te puede ir bien, pero la sección de propiedades inmobiliarias te va a ir lenta, porque no tiene cachés. De estas me he contado, de tener formularios que están en medio de la página, cuando desde mi punto de vista, si lo están, no deberían tener la caché invalida, puede usar un captcha. Una solución es que tengas un botón de mostrar formulario, que te salga un popup, un modal, o que el formulario se cargue justo debajo del botón, o que reemprese el botón, que lo cargue básicamente vía Ajax. La otra solución es no usar re-capcha y usar otras soluciones anti-bots que no invaliden las cachés de Rupal, que también las hay. ¿Qué más así que comentar? Ah, y así que es verdad, de contenidos que se pueden eliminar. Hubo un caso de un proyecto de un cliente, de que tiempo atrás, el que desarrolló la web, supongo que por requisitos del propio cliente, había un tipo de contenido que eran unas landing pages, unas páginas de aterrizaje, que se montaban sobre... bueno, se pueden arrasar contenidos y mostrar textos, imágenes y cosas varias. Además, de forma automática, dependiendo de las taxonomías que tenían asignadas, se mostraba un listado de taxonomías, de pedón, de nodos, que tenían esa misma taxonomía. Si imaginemos, me estoy inventando las categorías, pero imaginemos que tenemos una categoría de coches y una de motos. Pues si tenemos una landing page que está hablando de coches, debajo habrá un listado de los coches que están dentro de la categoría coches. Hasta aquí, ningún problema. El problema vino de que en algún momento, el cliente dijo que esto no lo quería, que se podía eliminar, y la persona encargada de hacer eso, en vez de eliminar todo el código, lo que hizo fue meter un displaynone. O sea, un ocultad por css. El código se seguía ejecutando, el código seguía generando un html y se seguía mostrando en el html de la web, pero visualmente estaba oculto con un displaynone. El problema era que ese listado no estaba paginado. No daba problemas cuando teníamos páginas con una categoría donde habían pocos nodos. Imaginemos que la web, siguiendo el ejemplo de coches y motos, tenga solo 10 motos, pues la landing de las motos va a mostrar solo un listado de 10. Pero imaginemos que la de coches tiene 100 coches. Pues estamos mostrando un listado de 100 items con imágenes y texto. Pues digamos, era un caso bastante similar a lo que fue realmente. No era de esto de coches y motos, pero digamos, se entiende la casuística. Tenemos un listado infinito con todos los items de una categoría. Si la categoría tiene muchos items, todas las landings que tengan esa categoría van a tener un problema de rendimiento de que tardan mucho en cargar. Además, por una cosa que realmente nos está mostrando, que se podía eliminar ese código. Pues la solución en ese caso fue un, pues si esto no se usa, pues se elimina y que ya no haga ese cálculo. Que no muestres este listado. Otra solución es si realmente se ha demostrado ese listado, pues se limita, se hace una paginación y que no te muestre ilimitados. Te muestre, por que yo que sé, los primeros 4 o 5 y un botón de ver más y que por allá que te vaya mostrando más si tú quieres. Por eso, son casuísticas. O por ejemplo también en otros casos, los listados del blog, pues que no te muestre 50 artículos, que te muestre solo de los primeros 10, por decir algo. O productos, lo mismo, que no te muestre aquí 25 productos, quizás solo con los primeros 12 ya te sirve y si haces scroll, que automáticamente o con un botón de cargar más, te cargue por Ajax los 12 siguientes. Y vas viendo de 2 en 12, como si fuera un infinite scroll, como lo de Twitter, que vas haciendo scroll y va bajando más y te van cargando más. No hace falta que los cargues todos de golpe. Pues son cosas de estas que al final afectan al rendimiento, porque al final son cálculos que se hacen a nivel de servidor en PHP y después se muestran en el frontend. Y todo el tiempo que tarda el servidor en calcular cosas es tiempo que el frontend, la persona que está en el ordenador, está esperando. Y eso normalmente, cuanto es más de un segundo, dos segundos, la gente dice, uy, es que esto es lento. O sea, lo suyo sería que tardasen menos de un segundo o segundo y medio, como mucho, no mucho más. Y por temas de SEO, cuanto más rápido, mejor. A poder ser menos de un segundo. Aún así, hay muchas webs, en Drupal al menos, que van mucho más lentas de lo que deberían y en muchos casos son o malas configuraciones o que hay un código hecho a medida muy mal optimizado. Y ya está, por lo que no sé qué más contar del tema este. Recomiendo muchísimo New Relic. Juega ya que tiene la versión gratuita, aunque yo tengo la de pago. Si quieres, aparte, aunque no tenga la gratuita, me suena que tenía un trial también, la de pago, de una semana, puedes probarlo. Recomiendo mucho tenerla en producción, aún así, como digo, muchos clientes no lo quieren tener en producción porque al final tienen un coste para mantenerla en producción. Porque depende de la cantidad de datos que tengas. Si tienes una web muy grande con muchas visitas, generas muchos más datos, lo cual al final tiene un mayor coste. Pero realmente, tener estadísticas de qué está pasando en producción, también ver de que la semana pasada tenías estos tiempos de respuesta y esta semana, justo por casualidad, después de un deploy que se han hecho X cambios, ahora en general la web va mucho más lenta. Y lo ves en las estadísticas, que son los numeritos, y estás viendo que es MySQL el que está dando problemas, puedes decirte, del último deploy, ¿qué ha hecho que afecte a MySQL y en concreto que afecte a este tipo de páginas? Pues digamos, detectas mucho más rápido que se han subido cosas mal hechas a producción. Por eso a mí me encanta New Relic. Y aún así, he visto que se usa muy poco. Todo esto también como recomendación. Hace tiempo que no trabajo con ellos, pero los de Pantheon, Pantheon es un hosting para Drupal, carillo, bastante caro. En su día, hace unos años, que trabajé con clientes que tenían webs allí, incluían gratuitamente, ya pagas el hosting, que no es barato, incluían New Relic. Es una cosa ten en cuenta. Pantheon es caro, pero tienes un servidor de desarrollo, pre-producción y producción, y además te incluyen New Relic, cosa que no está nada mal. Y poco más, no sé qué más contarte. Así que la semana que viene no, porque no voy a grabar. De aquí dos semanas, otro nuevo episodio. Estate atento. Chao.