Cómo mejorar el rendimiento de una web desarrollada con eZ Publish. (I)
Muchas veces, cuando entregamos un proyecto, nos econtramos con pegas de terceros del tipo "es que eZ Publish necesita demasiada máquina". Nuestra opinión es que si bien elementos ajenos a la aplicación, de las que hablaremos en siguientes posts (correcta configuración de la(s) máquina(s), instalación de reverse proxys, etc), jugarán un papel fundamental en el rendimiento de la aplicación, muchos de los problemas de rendimiento pueden ser paliados desde la propia aplicación, ya sea activando cachés o cambiando el modo en el que ciertos contenidos son generados y presentados.
Para aliviar la carga, eZ ofrece un completo sistema de caches que iremos viendo poco a poco. Por defecto, la instalación de eZ dejará activados casi todos ellos. A la hora de desarrollar un proyecto tienes dos opciones.
-
Dejar todo tal y como viene, es decir, con los caches activados. De esta forma podrás determinar si al publicar un contenido, los contenidos relacionados con él son también actualizados de forma automática y en caso contrario, hacer lo necesario para que esto ocurra.
En este caso deberás borrar manualmente los caches cada vez que modifiques alguna plantilla.
- Desactivar todo tipo de caches, lo cual está bien para desarrollar, pero nunca olvides activarlos en un paso a producción. Los contras de esta opción es que al tener desactivados los caches, todo se actualiza automáticamente. Recomendamos que previo paso a produccion, actives los caches y hagas las correspondientes pruebas de ediciones o adiciones de contenido para determinar si las acciones que quieres que ocurran (actualizaciones modulos tipo "nubes de tags" o "últimos contenidos", por ejemplo) se actualizan convenientemente.
Para determinar de donde vienen los problemas, tanto con caches activados como sin ellos, la herramienta fundamental para determinar de donde vienen los problemas es el propio debug que eZ Publish ofrece. El debug, aparte de indicarnos cualquier problema con nuestras plantillas o los php incluidos en nuestras extensiones, nos dirá tabmbién los tiempos de carga de una página y nos dirá que porcentaje ha jugado cada uno de los elementos que intervienen en la construcción de la página (parseado de plantillas, consultas a base de datos, archivos de traducciones...).
La siguiente captura muestra una pequeña parte de la información que obtenemos teniendo el debug activado. Está sacado de la pagina principal que obtenemos al instalar ez 4.0.3, con el paquete ezwebin instalado y con todos los caches desactivados.
Ahora vamos a ver esta misma figura una vez se han activado los caches.
La diferencia es sustancial. Pero, ¿qué es lo que ha cambiado? Vamos por partes. Observando la imagen 1, vemos que un apartado llamado "Template processing" se lleva algo más del 65% total de la carga. eZ Publish usa su propio motor de plantillas, (que a algunos os recordará a Smarty). De esta forma se puede separar totalmente la presentación del contenido y, usando unicamente las funciones predefinidas, uno puede constuir su site sin temor a que su codigo php pueda hacer alguna operación no deseada en la base de datos.
Pero, no lo olvidemos, esto sigue siendo PHP y para que esto funcione, hay algo que tiene que transformar el "código plantilla" en "código php". Esta transformación es costosa y por eso, eZ permite que ese codigo php generado quede guardado en disco de tal manera que nos ahorremos el proceso de transformación. Tras un vaciado de este cache el proceso de transformación vuelve a ejecutarse para la regerenación de este código php. el valor asignado a TemplateCompile.
Otra gran diferencia la tenemos en el valor "Mysql Queries". El valor indica el número de consultas que han sido necesarias ejecutar para la presentación de la página. Podemos ver que ha pasado de... ¡165 a 1!. No lo dudes, cualquier aplicación, sea o no eZ Publish, irá "más rápida" cuanto menos uso haga de la base de datos. Dejando a la base de datos tranquila tu aplicación se beneficiará, pero también la harán otras aplicaciones que hagan uso de ese mismo servidor, cosa más que común en hostings compartidos.
La explicación está en el ViewCaching. Activando éste, el codigo generado por esas 165 queries es guardado en un archivo con unas propiedades determinadas. En siguientes peticiones, eZ, antes de realizar cualquier consulta a la Base de Datos, comprobará si puede saltárselas gracias a ese archivo que previamente ha guardado. Evitando estas consultas, el tiempo de generacion de la página es menor.
Esto está muy bien y es perfecto para webs con poco dinamismo. Pero, ¿qué ocurre cuando pensamos en una web que si que necesita dinamismo, tipo periódicos on-line?. Bien, eZ tiene definidas por defecto unas políticas de regeneración de caches que estudiaremos en próximos posts. Por ejemplo, cada vez que un nodo es editado, el cache asociado a él es regenerado. también lo es si se edita alguno de sus "hijos" o incluso si el editado es un nodo relacionado con él.
En nuestro ejemplo, cada vez que ocurriese alguna de estas cosas, esas 165 consultas volverían aparecer, por lo que, si bien es perfecto tener el viewCaching hay que tener cuidado con lo que ocurre con la regeneración de los mismos. Más aún cuando somos nosotros los que creamos extensiones para ciertas partes del site. En ocasiones, una simple consulta puede ser la causa de todos los problemas de rendimiento de un site.
Para ver qué son todas esas consultas, eZ nos permite activar el llamado SQLOutput . Con ello se nos mostrará por pantalla todas y cada una de las consultas ejecutadas y, lo que es aún más útil, el tiempo que ha tardado en ejecutarse cada una de ellas y el número de filas resultado obtenidas.
Procura que tus consultas no devuelvan más de las filas necesarias. Un caso típico de esto es obtener en una consulta 100 o 1000 registros para después mostrar unicamente 10. (veremos ejemplos en próximos posts).
Este debug de consultas no se queda ahí, sino que además podemás activar el QueryAnalisisOutput (para obtener los EXPLAIN de cada SELECT), o configurar el SlowQueriesOutput, para solo mostrar las consultas que tarden más de x segundos, con el fin de centrarnos en su optimización.
En próximos posts veremos que las políticas de vaciado de caches que eZ trae por defecto, no siempre sirven para nuestras necesidades. Las cosas empiezan a complicarse cuando necesitamos colocar en nuestra home algo del tipo "Artículos más comentados", o "Artículos más votados"... y en mayor medida, cuando pensamos en algo que no depende de la publicación de un contenido, sino, por ejemplo, de un cambio automatico relacionado con un cambio de fecha.
Veremos entonces que podremos configurar eZ para los siguientes casos.
- Cachear todo el site excepto la home. Lo cual no parece una solución del todo apropiada. al fin y al cabo, la mayor parte de nuestras visitas van a entrar por la home. Si por cada visita necesitamos ejecutar las 165 consultas de arriba, podemos tener problemas en el momento en el que nuestras visitas crezcan.
- Regenerar la home solo ante determinadas acciones. Si bien eZ tiene sus políticas predefinidas, nosotros podremos añadirle más a través del SmartCache o de los métodos de la clase eZContentCacheManager
- Dejar la home cacheada durante x tiempo (perderemos cierto dinamismo, pero evitaremos carga a la DB)
- Usar elStaticCache, para genera una versión en html puro de la página, con lo cual evitaremos TODAS las consultas a la base de datos.
A partir de aquí, es cuestión siempre de determinar que es lo que más necesita tu web. ¿Quieres que todo se actualice al instante a costa de que la carga de ralentice o prefieres que las páginas se sirvan rápido aunque el usuario no vea las actualizaciones hasta cinco minutos después de que se produzcan?
En definitiva, tener una buena infraestructura es fundamental para dar un buen servicio, pero hay ocasiones en los que la entrada de visitas en tu web es inesperada (un enlace en meneame, un anuncio en prensa, una cita en televisión... ). Antes estas situaciones, poner más máquinas te va a ayudar pero mientras estas máquinas te llegan estás ante un problema. eZ te va a permitir de forma sencilla reconfigurar tus caches para tratar de mantener tu web viva mientras llegan los refuerzos. Una vez tengamos estos refuerzos veremos como añadir elementos a nuestro aplicativo para tratar de que nuestra web sirva páginas al mayor número de gente posible y con la mayor celeridad posible.
Always good to see eZ Publish blogs. My spanish is not that fluent, but Google Translate works out pretty well. Consider adding this to the sidebar: http://translate.google.com/translate_tools
Thanks for your comment. Sure we'll consider this. Home you come buck soon :)
H9Lh9y <a href="http://ydnrdmsltiuf.com/">ydnrdmsltiuf</a>, [url=http://mactfzwmwfkz.com/]mactfzwmwfkz[/url], [link=http://uixjosjaxjvm.com/]uixjosjaxjvm[/link], http://vallhhnouqvl.com/
It was dark when I woke. This is a ray of snsuinhe.
ZVV1wF , [url=http://tyzfpoprzujb.com/]tyzfpoprzujb[/url], [link=http://qktmhifeyewg.com/]qktmhifeyewg[/link], http://xtrqwxnfuiid.com/
jkDQWF <a href="http://qsrbftiffvok.com/">qsrbftiffvok</a>
EsIYEN , [url=http://gjcovslfnroz.com/]gjcovslfnroz[/url], [link=http://eujyuockjigb.com/]eujyuockjigb[/link], http://lopmbxfordcw.com/