Planeta DH

Herta Security: Nueva web con Drupal 8

Atenea tech - Blog -

Empezamos el nuevo año hablando de un nuevo proyecto que hemos realizado en el último trimestre de 2016.

Herta Security es una empresa líder mundial en innovación en reconocimiento facial. Con sede en Barcelona y oficinas en Madrid, Londres y Los Ángeles, la compañía ha desarrollado una tecnología revolucionaria en el ámbito del reconocimiento facial, especializándose en la identificación sobre multitudes en tiempo real a través de cámaras IP.

En Atenea tech hemos desarrollado su nueva web con Drupal 8 responsive y multi-idioma, creando un espacio especial para productos y sectores, además de potenciar todo lo relacionado con la comunicación; notícias, eventos, blogs y publicaciones.

Además, cuenta con una intranet privada para que los clientes puedan acceder a servicios personalizados, como documentos privados.

Nuevo proyecto Drupal: Web del Ayuntamiento de Sant Joan Despí

Atenea tech - Blog -

Hoy tengo el placer de presentaros un nuevo proyecto realizado en Atenea tech. Se trata de la web municipal de Sant Joan Despí, ciudad de más de treita-tres mil habitantes del área metropolitana de Barcelona.

El departamento de prensa del ayuntamiento nos encargó un proyecto que fuera dinámico, y que les permitiese tener muchas alternativas a la hora de publicar notícias y actividades. En este sentido, realizamos un trabajo minucioso en la creación de los esquemas de pantalla y las estructuras de datos, creando una estructura en rejilla que permitía publicar un contenido en diferentes lugares dependiendo de su tipología (sección). Las secciones, aunque son libres, tienen su correspondencia en las diferentes regidorías de la ciudad, y permiten mezclar diferentes tipos de contenido (notícias, actividades, galerías, equipamientos, etc.).

A todo ello se suma la posibilidad de publicación según sección y usuario, creando una web con una gestión de la publicación profesional.

Otra de las prioridades era tener una versión responsive para la web, y que los ciudadanos pudieran navegar desde sus móviles y tables sin el menor problema.

Pese a ser el proyecto más grande realizado hasta la fecha, con el ayuntamiento de Sant Joan Despí ya hemos realizado varios proyectos relacionados con instalaciones deportivas, así como otras áreas de actuación, como la nueva ciudadania o la agenda del alcalde.

Nuestra experiencia en la WordCamp Barcelona

Atenea tech - Blog -

El pasado viernes Luis y yo nos presentamos, en plan kamikaze, a dar una charla sobre Drupal en la WordCamp Barcelona. Para los neófitos en el tema, deciros que una WordCamp son unas jornadas sobre WordPress. En este caso, nosotros nos propusimos a hacer una charla sobre Drupal, para que la gente de WordPress conociera mejor a otro CMS.

La WordCamp se realizó en el CosmoCaixa, el antiguamente conocido como Museu de la Ciencia de Barcelona. En este sentido, la WordCamp ocupó uno de los pisos del CosmoCaixa, donde contaba con dos salas increíbles, además de una zona para los patrocinadores. Me comentaron que fueron más de 275 entradas vendidas, no está nada mal.

Foto de Ramon Iglesias.

En nuestro caso, estuvimos realizando la charla en el Auditorio, y la verdad es que los 20 minutos de charla no dieron para entrar en profundidad sobre Drupal, pero si que nos permitió dar alguna pincelada de qué tipo de webs creemos que es mejor hacerlas con Drupal, y que webs es preferible hacer con WordPress. Creemos que, para webs complejas como pueden ser grandes corporaciones, Publicaciones extensas -diario, media-, intranets, redes sociales, y en general webs con muchas funcionalidades, Drupal es una buena elección, aunque podríamos discutir mucho con esto (los asistentes no nos cosieron a preguntas, así que supongo que estarán de acuerdo con nosotros :D ).

Por la noche, en la cena de ponentes, los Wordpreseros nos acogieron con los brazos abiertos, y estuvimos hablando de realizar charlas más genéricas sobre gestores de contenidos (Open Source, claro!) en Barcelona. Seguro que nos animamos pronto a hacer más cosas con la Comunidad de WordPress y sobretodo con Joan Artés de Artesans, al cual quiero agradecer personalmente que no le sonara a locura lo de realizar una charla de Drupal en una WordCamp.

Drupal & Beers: Gestión de configuración en Drupal 8

Atenea tech - Blog -

El próximo 24 de noviembre Drupal.cat organiza un nuevo Drupal & Beers. En este caso nos hace especial ilusión anunciar que Robert Menetray, programador de Atenea tech, se animará a hablar sobre CMI (Configuration Management Initiative) en Drupal 8

Algunos temas que se tratarán serán:

  • Cómo usarlo desde interfaz y desde drush.
  • Módulos que ayudan a simplificar el trabajo.
  • Cómo sobrescribir valores para poder tener configuraciones distintas entre entornos.
  • Cómo evitar que se exporten configuraciones de algunos módulos y evitar que se activen módulos que solo deben de estar en el entorno de desarrollo. 

Además, Robert se animará a realizar una demo en vivo.

El lugar de celebración será un bar de un amigo muy especial, Robert Garrigós, que después de perder muchas neuronas arreglando parches de Drupal ahora regenta Barcelona Bagers, en la calle Còrsega, 398 de Barcelona -Metro Verdaguer(L4/L5) o Diagonal (L3/L5)-.

Si os animáis, mejor reservad sitio aquí! Os esperamos!

Seremos ponentes en la WordCamp Barcelona 2016

Atenea tech - Blog -

Ya podemos confirmar la notícia! Y es que Luis y yo realizaremos una charla sobre Drupal en la WordCamp Barcelona 2016.

Un momento.. ¿una charla sobre Drupal en la WordCamp? Para todos aquellos que no sepan qué es una WordCamp, os explicaré que es una reunión de dos días en la que se presentan charlas y se realiza networking alrededor de un tema en común, Wordpress. Pero.. entonces, qué sentido tiene una charla de Drupal en una encuentro de WordPress? Pues creo que lo entenderéis mejor si os digo el título de la charla: "Drupal 8: Conoce a tu enemigo".

La idea de esta charla surgió durante la charla que realizamos unas semanas atrás junto a las comunidades de Wordpress y Joomla para hablar de estos 3 gestores de contenidos. En este sentido, pude observar como cada comunidad va a lo suyo, y muchas veces no conocemos demasiado de otras tecnologías muy cercanas a la que solemos utilizar. En mi caso, soy más conocedor de Wordpress, pero Joomla! para mi es un total desconocido, y tengo que reconocer que tiene puntos muy interesantes que ni siquiera imaginaba.

Llevado por esta sensación, propuse junto a Luis una charla en la WordCamp en la que expliquemos qué es Drupal 8. Así damos a conocer Drupal, y nos quitamos alguna de las etiquetas y prejuicios que tiene toda tecnología. Además, aprovecharemos para aprender más sobre WordPress y su comunidad, que tan bien nos han acogido hasta ahora. Además, la WordCamp se celebra en un sitio muy especial, el CosmoCaixa. Así que si estáis en Barcelona el 2 y 3 de diciembre, os animo a que vengáis a conocer un poco más sobre WordPress (y un poquito sobre Drupal) en la WordCamp.

Presentación de Drupal 8 en la UPC

Atenea tech - Blog -

El pasado miércoles 9 de noviembre tuvimos el placer de presentar las novedades de Drupal 8 en la Universidad Politècnica de Catalunya (UPC), dentro del marco de las Jornada TIC 2016. Este meeting tiene por objetivo acercar la innovación a los profesionales de la universidad mediante charlas y posters.

En nuestro caso, fuimos invitados a hablar de Drupal 8, un sistema que ya se utiliza en la universidad, pero sobretodo en su versión anterior. Los asistentes, muchos antiguos conocidos de Drupal, tuvieron la posibilidad de conocer las nuevas herramientas que pone Drupal 8 a su alcance. Fue especialmente espectacular enseñar algunas de las nuevas funcionalidades de Drupal 8, como BigPipe, o la edición exprés.

Para nosotros fue la oportunidad de volver a nuestra universidad de orígen, y de promocionar Drupal en el ámbito educativo, donde ya tiene una implantación muy importante con algunas iniciativas muy interesantes como Drupal UPC. Y por supuesto, aprovechar para hacer la peregrinación al bar de la facultad, que tan buenos recuerdos nos trae :)

Tutorial: Crear un listado de noticias en Drupal 8

Atenea tech - Blog -

Anteriormente os hablé de cómo realizar una galería de imágenes en Drupal 8. En esta ocasión vamos con un tutorial, incluso más sencillo: crear una sección de notícias en nuestra web con Drupal 8.

1. Crear tipo de contenido Notícia

Crearemos un nuevo tipo de contenido al que llamaremos Notícia (Estructura → Tipos de contenido → Añadir tipo de contenido).

Por defecto, en Drupal 8, cuando creamos un nuevo tipo de contenido, tenemos dos campos, Título y Cuerpo. Además de eso, para hacer un poco más completo el tutorial, añadiremos un campo Imagen Principal a la notícia:

Además de añadir el campo de comentarios:

Una vez añadidos estos campos, vamos a la pestaña de Administrar presentación, y configuramos la imagen para que tenga un estilo de imagen predeterminado:

 

2. Creamos la vista

Crearemos la vista Noticias (Estructura → Vistas → Añadir nueva vista) tal como se muestra en la siguiente imagen:

Una vez hecho esto, ya podremos ir a visitar nuestra página de Notícias:

 

BONUS:

Como habréis podido comprobar en el listado anterior, las notícias están escritas en latín (no tienen significado, sólo son palabras sueltas). Para generar este contenido, hemos utilizado el módulo Devel Generate. Para ello, tenéis que instalar el módulo Devel y activar Devel Generate. Una vez hecho esto, vamos a la página de generación de contenido Dummy (Configuración → Generate Content).

En esta página indicamos el tipo de contenido que queremos generar, el número de nodos y otras opciones. Una vez hecho esto, tendréis un gran listado de contenido que os servirá para probar las funcionalidades de vuestra web en Drupal 8. También podréis borrar el contenido automático generado desde la misma página.

Unicef.es y las posibilidades de Drupal 8

Biko2 -

Hace unos meses hablábamos sobre cómo Drupal busca salir de la isla, asociarse a otros proyectos open source y de esa manera hacer el ecosistema php más consistente. La publicación de Unicef.es viene a demostrar que esto es cierto.

Drupal 8 aporta la consistencia que necesita un sector poderoso como es el de la gestión de contenidos. El desarrollo web ha cambiado y nuestros ecosistemas de software tiene que adaptarse y tener en cuenta las buenas prácticas en el desarrollo, los sistemas basados en API, el diseño “atómico/modular”, los dispositivos y sus soportes, la gestión de despliegues, y el soporte multilingüe. Y después de haber participado en el desarrollo de Unicef.es podemos confirmar que esto es así.

Desde el principio asumíamos este proyecto como un reto. Un reto compartido con KPMG, SBIT y 540. Un reto en el que hemos tenido que aprender rápidamente la potencia oculta de Drupal 8, descubrir sus grandes posibilidades y sufrir en algunos casos por su falta de madurez. Pero eso sí, podemos decir que Drupal 8 sigue siendo el mejor gestor de contenidos del mercado.

Son muchos los detalles que podríamos comentar del desarrollo y en algunos ellos profundizaremos en posteriores posts. Pero rescatamos algunos de los que nos parecen más relevantes:

  • Unicef.es  es un Drupal pensado para gestionar landigs. Se ha creado un conjunto muy completo de componentes que son lo que se usan para construir portadas en cualquier parte de sitio con cualquier propósito.
  • Los formularios de donación y suscripción se han desarrollado para integrarse en el sistema de landings con el objetivo de tener el mayor impacto y compromiso posible.
  • Drupal 8 se adapta a cualquier dispositivo. Pero en el desarrollo hemos ido más allá, trabajando estrechamente con KPMG, incluyendo herramientas en la propia gestión de contenidos que permiten definir diferentes puntos de ruptura dependiendo del dispositivo.
  • Hemos descubierto las posibilidades de CMI, el mecanismo que Drupal 8 incorpora para la gestión de despliegues. Con stbio.io y las herramientas utilizadas (Gitlab, Jenkis, Ansistrano) podemos hablar de que el devops en Drupal 8 es una realidad. En serio, que no os engañen, en PHP se puede hacer código de calidad con herramientas de calidad.
  • Uno de los objetivos en Unicef.es era conectar la gestión de contenidos con su unidad de negocio gestionada por su propio CRM. El equipo de 540, en su mejor estilo craftsmanship ha desarrollado una librería PHP independiente, que permite conectar Drupal con el CRM. Hemos comprobado que la potencia de esta parte del desarrollo es increíble.

En definitiva, la nueva Unicef.es está dando sus primeros pasos y nos alegra haber ayudado en ello. Es un gran proyecto con un gran propósito y de alguna manera esperamos que también pueda servir de inspiración.

Intranet corporativa con LDAP y Drupal para Conforama

Atenea tech - Blog -

Conforama es una de las marcas más reconocibles de muebles. De origen francés, su sede española nos pidió la realización de una intranet para compartir información y artículo con los empleados de las diferentes tiendas de España y Portugal. Para ello, realizamos un proyecto de Intranet con Drupal, al cual añadimos la posibilidad de registro de usuario utilizando la LDAP de Conforama, de tal manera que los usuarios se logasen directamente en la web sin necesidad de crear un nuevo usuario en Drupal. De esta forma, facilitamos la utilización de la plataforma, haciendo más accesible y utilizada la misma.

 

Drupal es una plataforma ideal para la realización de Intranets, ya que incorpora por definición en su filosofía una herramienta de identificación de usuarios y roles. Además, con la incorporación de módulos adiccionales, como el ya mencionado LDAP, podemos adaptarnos rápidamente a las herramientas que ya utilizan las empresas.

Resumen de la batalla: Drupal vs WordPress vs Joomla!

Atenea tech - Blog -

Pese a lo rimbombante del título, la charla realizada el pasado lunes 17 de octubre en el Mobile World Centre fue todo excepto una batalla. Vamos allá con el resumen de lo acontecido:

Antes de empezar, me gustaría de nuevo dar las gracias a los responsables del Mobile World Centre, un espacio de Movistar en el centro de Barcelona que nos cedieron gratuitamente. El lugar es fantástico, así como los medios puestos a nuestra disposición. Realizar una charla en este lugar es una pasada, y además los asistentes agradecen que el lugar sea tan céntrico (Pza Cataluña!). De nuevo, muchas gracias.

En cuanto a la charla, lo primero que realizamos fue una pequeña presentación de cada uno de los CMSs. Empezaron los Joomleros (@jdevelopia y Jordi Sala), hablando de las bondades de su CMS favorito. Después fue el turno de @luisortizramos, que realizó una rápida presentación de Drupal llamada "Drupal in a nutshell", en la que más que entrar en detalles, daba pistas de los temas más interesantes de Drupal 8. Por último, @josecontic nos habló de WordPress desde su experiencia tanto en la comunidad de Barcelona, como en el desarrollo de un pluguin llamado Wanguard (que precisamente ahora está recaudando de fondos para continuar con su desarrollo). Y para dirigir el cotarro y moderar, contamos con la ayuda de @joan_artes, que también fue el responsable de montar el evento.

Después fue el momento de la mesa redonda, donde @lonchbox fue planteando una serie de temas en los que pudimos entrar en detalle. El que más dió de hablar fue el de la seguridad, donde @josecontic y yo mismo estuvimos hablando sobre lo idóneo de que hayan pluguins de pago en WordPress, y los problemas de seguridad que eso puede plantear.

Finalmente tuvimos un turno de preguntas, en las que los asistentes nos preguntaron sobre migraciones, accessibilidad, actualizaciones y otros temas. En general, los representantes de los 3 CMSs compartimos detalles interesantes sobre cada uno de estas 3 tecnologías, pero no hubo demasiada polémica, porque creo que cada uno de nosotros sabe para que tipo de web y para que tipo de cliente es mejor cada tipo de gestor de contenidos.

Para sintetizarlo en un gráfico como el que muestro a continuación, hay muchas más webs WordPress que Drupal, pero las webs realizadas con Drupal son más grandes (tienen mucho más contenido y consultas):

Personalmente creo que es muy interesante este tipo de charlas, porque conoces gente de otras comunidades con las que compartimos el hecho de que hablamos de Open Source. En eso, estamos todos muy de acuerdo!

Por último, os enlazo la galería de fotos del evento. ¡Hasta la próxima!

Profiling en Drupal: Un caso práctico

Biko2 -

Durante este verano hemos estado trabajando en la migración del portal del Museo Reina Sofía, en el que continuamente estamos aplicando mejoras, a un nuevo proveedor de hosting. El ecosistema hardware y software del museo se compone de una implantación bastante compleja de Drupal 7 como CMS y Apache Solr como indexador y buscador de contenidos.

A nivel de infraestructura hardware los diferentes portales del museo están desplegados en una infraestructura virtualizada en alta disponibilidad que incluye dos servidores frontales que incorporan Varnish como proxy inverso para cachear peticiones, apache con php5 como servidor de aplicaciones y memcache para el cacheo en memoria de Drupal. A nivel de base de datos disponemos de un cluster maestro-esclavo de Mysql en servidores separados que alojan también el servicio de búsquedas basado en Solr 4 en una implantación clusterizada.

El portal principal del Museo recibe bastante tráfico (incluido un rastreo continuo por parte de indexadores) que hace que cuidemos bastante el rendimiento del portal y su disponibilidad.

El problema

En el proceso de puesta en producción de la nueva infraestructura nos encontramos con un problema difícil de solucionar. Esporádicamente algunas páginas de edición de contenidos en el CMS tenían tiempos de renderizado de más de 20 segundos (llegando incluso a 40 segundos algunas de ellas), lo que dificultaba el trabajo de los editores de contenidos que continuamente están alimentando el portal.

El problema se podía demostrar fácilmente activando el módulo devel y configurándolo para que mostrase el tiempo de ejecución de página y las consultas a base de datos realizadas.

Una ejecución de una de las páginas en cuestión hacía aflorar el problema. Después de bastantes pruebas, identificamos que normalmente ocurría cuando el sistema tenía las caches de Drupal vacías (aunque ocurría esporádicamente también). La primera petición a una página de edición de un contenido devolvía tiempos de ejecución superiores a 20 segundos, la segunda petición ya daba tiempos normales (entre 1 o 2 segundos de ejecución total).

Después de verificar mil veces toda la configuración de los nuevos servidores, no encontrábamos el problema, además estábamos prácticamente seguros de que era un problema de configuración o potencia de los nuevos servidores, ya que en la infraestructura anterior el problema no ocurría nunca y podíamos compararlas en condiciones similares.

Primera tentativa de solución: ¡más hierro! Aunque habíamos verificado que los tiempos de ejecución de la capa de base de datos eran similares a los de la infraestructura anterior, no me resistía a pensar que el principal cuello de botella de Drupal era el responsable de todo esto, o sea, más potencia a la base de datos, más memoria a los frontales y más CPU a toda la infraestructura. ¿Mejora? ¡Ninguna! Además el log del módulo devel ya lo decía: tiempo de ejecución de llamadas a BD 3 segundos, tiempo de ejecución de página 30 segundos (en este caso la llamada a base de datos es muy lenta porque teníamos activado todo el debug ya para intentar localizar el problema).

Segundo intento: ¡simplificación! Estaba claro que teníamos algún bloqueo esporádico con algún recurso externo, lo primero en lo que pensé fue en alguna configuración errónea de memcache o apache solr de los que depende la infraestructura para muchas peticiones. Fuimos quitando uno a uno cada uno de estos servicios, pero el problema seguía ahí.

Tercer intento: ¡profiling! Teniendo en cuenta que esto solo lo reproducíamos en los servidores de producción y que estaban ya en activo, me resistía a meter una herramienta que afectase al servicio, pero visto que no encontrábamos el problema, nos decantamos por sacar uno de los frontales de nuestro balanceador y utilizar una herramienta de profiling para intentar localizar el problema. Vamos con los detalles.

Profiling al rescate

Para los que no lo sepáis, una herramienta de profiling permite analizar al detalle qué está ocurriendo con una petición a nivel de tiempos de ejecución y consumo de memoria de cada función por la que pasa la petición al servidor. Existen muchas herramientas de profiling, para este caso me decanté por usar la herramienta desarrollada por facebook: xhprof ya que su integración con Drupal 7 está muy documentada.

No me alargaré en la instalación de la herramienta y su integración con Drupal 7, es algo bastante sencillo de realizar con muchas referencias en internet (yo seguí este post). Una vez que todo está configurado (incluida la integración con el módulo devel de Drupal), cada petición al servidor mostrará un link en el pie de página que permite acceder al informe de profiling de dicha página.

Realmente lo difícil con xhprof es saber interpretar los resultados, así que intentaré aportar mi granito de arena con cómo he analizado los informes para dar con el problema, realmente estamos ante un caso sencillo pero muy común.

El informe de xhprof nada más abrirlo muestra 2 zonas:

  • Resumen de la petición: en este resumen podemos ver los grandes números de la petición analizada y nuestro problema. 19,6 segundos de ejecución de los cuales solo 2,5 son de consumo de CPU.
  • Principales funciones ejecutadas: en esta tabla se muestran las principales funciones ejecutadas con posibilidad de ordenarlas por diferentes criterios.

La forma de usar este informe consiste en trabajar sobre la ordenación de esta tabla de funciones, ya que cada columna representa un concepto diferente. Inicialmente la tabla viene ordenada por la columna “Included Wall Time”), que muestra el tiempo total de ejecución de cada función, incluido el tiempo de la propia función. Esta visualización normalmente no dice grandes cosas, al menos si buscamos funciones que estén consumiendo mucho tiempo de ejecución (como es mi caso). Lo único que vemos es que la función main ocupa el 100 % del tiempo de ejecución (ya que es la que engloba toda la petición de Drupal).

Realmente para detectar el problema, en este caso de alto consumo de tiempo de ejecución, ordenaremos la tabla por “Excl. Wall Time”, que muestra el tiempo de ejecución de una función excluyendo el tiempo de ejecución de las funciones hijas. Y ¡voilà! aquí esta el culpable:

En este informe tenemos un resultado concluyente, la función de php file_get_contents está ocupando 15 segundos de tiempo de ejecución, y se ejecuta 128 veces. Pero… y ahora ¿cómo encuentro yo cuál de las llamadas a esa función está dando problemas? (en nuestra implantación de Drupal 7 se usa más de 100 veces). Aquí esta lo bueno, podemos navegar por el informe para obtener más información sobre esta función pulsando sobre el nombre de la misma:

Ya empiezo a ver la luz, ahora sí tengo un culpable que puedo diseccionar. En esta visualización podemos observar que la función drupal_build_js_cache es la que está consumiendo todo el tiempo de ejecución. Y analizando el código de dicha función, vemos que es la que se encarga de “empaquetar” todos los ficheros JS de la aplicación y generar un fichero con el agregado para optimizar el rendimiento del frontend. Y como el problema está en la llamada a file_get_contents de dicho fichero, parece que tenemos un problema con alguna lectura de alguno de esos ficheros en el servidor. ¿Pero cuál?, ¿será tema de permisos?, ¿será que el acceso a disco en los nuevos servidores es superlento? Bueno, no queda otra que debugear esta función, el problema es que como solo nos pasa en producción no podemos meter un debugger interactivo como xdebug, así que nos tendremos que servir de un simple log como este:

Y revisando el log generado por una petición que ha presentado el problema vemos lo siguiente:

¡2 ficheros JS que se están intentando empaquetar provienen no de un fichero local, sino de una llamada http!. En este caso la llamada http va contra nuestra propia máquina en un subdominio donde estamos sirviendo los ficheros estáticos para optimizar el rendimiento del frontend. ¿Y cuál es el problema? Este:

Resulta que los propios servidores no son capaces de acceder por http a sí mismos. Esto es lo que provoca el bloqueo y los tiempos de espera hasta que la función file_get_contents da un timeout.

La solución

Que los servidores resuelvan esa petición. Lección aprendida después de dedicar multitud de horas y recursos a intentar revisar el tunning del servidor, un profiling puede dar pistas de un problema puntual de rendimiento y ahorrar muchos dolores de cabeza como los que he tenido el último mes.

¡Gracias, xhprof!

Profiling en Drupal: Un caso práctico

Biko2 -

Durante este verano hemos estado trabajando en la migración del portal del Museo Reina Sofía, en el que continuamente estamos aplicando mejoras, a un nuevo proveedor de hosting. El ecosistema hardware y software del museo se compone de una implantación bastante compleja de Drupal 7 como CMS y Apache Solr como indexador y buscador de contenidos.

A nivel de infraestructura hardware los diferentes portales del museo están desplegados en una infraestructura virtualizada en alta disponibilidad que incluye dos servidores frontales que incorporan Varnish como proxy inverso para cachear peticiones, apache con php5 como servidor de aplicaciones y memcache para el cacheo en memoria de Drupal. A nivel de base de datos disponemos de un cluster maestro-esclavo de Mysql en servidores separados que alojan también el servicio de búsquedas basado en Solr 4 en una implantación clusterizada.

El portal principal del Museo recibe bastante tráfico (incluido un rastreo continuo por parte de indexadores) que hace que cuidemos bastante el rendimiento del portal y su disponibilidad.

El problema

En el proceso de puesta en producción de la nueva infraestructura nos encontramos con un problema difícil de solucionar. Esporádicamente algunas páginas de edición de contenidos en el CMS tenían tiempos de renderizado de más de 20 segundos (llegando incluso a 40 segundos algunas de ellas), lo que dificultaba el trabajo de los editores de contenidos que continuamente están alimentando el portal.

El problema se podía demostrar fácilmente activando el módulo devel y configurándolo para que mostrase el tiempo de ejecución de página y las consultas a base de datos realizadas.

Una ejecución de una de las páginas en cuestión hacía aflorar el problema. Después de bastantes pruebas, identificamos que normalmente ocurría cuando el sistema tenía las caches de Drupal vacías (aunque ocurría esporádicamente también). La primera petición a una página de edición de un contenido devolvía tiempos de ejecución superiores a 20 segundos, la segunda petición ya daba tiempos normales (entre 1 o 2 segundos de ejecución total).

Después de verificar mil veces toda la configuración de los nuevos servidores, no encontrábamos el problema, además estábamos prácticamente seguros de que era un problema de configuración o potencia de los nuevos servidores, ya que en la infraestructura anterior el problema no ocurría nunca y podíamos compararlas en condiciones similares.

Primera tentativa de solución: ¡más hierro! Aunque habíamos verificado que los tiempos de ejecución de la capa de base de datos eran similares a los de la infraestructura anterior, no me resistía a pensar que el principal cuello de botella de Drupal era el responsable de todo esto, o sea, más potencia a la base de datos, más memoria a los frontales y más CPU a toda la infraestructura. ¿Mejora? ¡Ninguna! Además el log del módulo devel ya lo decía: tiempo de ejecución de llamadas a BD 3 segundos, tiempo de ejecución de página 30 segundos (en este caso la llamada a base de datos es muy lenta porque teníamos activado todo el debug ya para intentar localizar el problema).

Segundo intento: ¡simplificación! Estaba claro que teníamos algún bloqueo esporádico con algún recurso externo, lo primero en lo que pensé fue en alguna configuración errónea de memcache o apache solr de los que depende la infraestructura para muchas peticiones. Fuimos quitando uno a uno cada uno de estos servicios, pero el problema seguía ahí.

Tercer intento: ¡profiling! Teniendo en cuenta que esto solo lo reproducíamos en los servidores de producción y que estaban ya en activo, me resistía a meter una herramienta que afectase al servicio, pero visto que no encontrábamos el problema, nos decantamos por sacar uno de los frontales de nuestro balanceador y utilizar una herramienta de profiling para intentar localizar el problema. Vamos con los detalles.

Profiling al rescate

Para los que no lo sepáis, una herramienta de profiling permite analizar al detalle qué está ocurriendo con una petición a nivel de tiempos de ejecución y consumo de memoria de cada función por la que pasa la petición al servidor. Existen muchas herramientas de profiling, para este caso me decanté por usar la herramienta desarrollada por facebook: xhprof ya que su integración con Drupal 7 está muy documentada.

No me alargaré en la instalación de la herramienta y su integración con Drupal 7, es algo bastante sencillo de realizar con muchas referencias en internet (yo seguí este post). Una vez que todo está configurado (incluida la integración con el módulo devel de Drupal), cada petición al servidor mostrará un link en el pie de página que permite acceder al informe de profiling de dicha página.

Realmente lo difícil con xhprof es saber interpretar los resultados, así que intentaré aportar mi granito de arena con cómo he analizado los informes para dar con el problema, realmente estamos ante un caso sencillo pero muy común.

El informe de xhprof nada más abrirlo muestra 2 zonas:

  • Resumen de la petición: en este resumen podemos ver los grandes números de la petición analizada y nuestro problema. 19,6 segundos de ejecución de los cuales solo 2,5 son de consumo de CPU.
  • Principales funciones ejecutadas: en esta tabla se muestran las principales funciones ejecutadas con posibilidad de ordenarlas por diferentes criterios.

La forma de usar este informe consiste en trabajar sobre la ordenación de esta tabla de funciones, ya que cada columna representa un concepto diferente. Inicialmente la tabla viene ordenada por la columna “Included Wall Time”), que muestra el tiempo total de ejecución de cada función, incluido el tiempo de la propia función. Esta visualización normalmente no dice grandes cosas, al menos si buscamos funciones que estén consumiendo mucho tiempo de ejecución (como es mi caso). Lo único que vemos es que la función main ocupa el 100 % del tiempo de ejecución (ya que es la que engloba toda la petición de Drupal).

Realmente para detectar el problema, en este caso de alto consumo de tiempo de ejecución, ordenaremos la tabla por “Excl. Wall Time”, que muestra el tiempo de ejecución de una función excluyendo el tiempo de ejecución de las funciones hijas. Y ¡voilà! aquí esta el culpable:

En este informe tenemos un resultado concluyente, la función de php file_get_contents está ocupando 15 segundos de tiempo de ejecución, y se ejecuta 128 veces. Pero… y ahora ¿cómo encuentro yo cuál de las llamadas a esa función está dando problemas? (en nuestra implantación de Drupal 7 se usa más de 100 veces). Aquí esta lo bueno, podemos navegar por el informe para obtener más información sobre esta función pulsando sobre el nombre de la misma:

Ya empiezo a ver la luz, ahora sí tengo un culpable que puedo diseccionar. En esta visualización podemos observar que la función drupal_build_js_cache es la que está consumiendo todo el tiempo de ejecución. Y analizando el código de dicha función, vemos que es la que se encarga de “empaquetar” todos los ficheros JS de la aplicación y generar un fichero con el agregado para optimizar el rendimiento del frontend. Y como el problema está en la llamada a file_get_contents de dicho fichero, parece que tenemos un problema con alguna lectura de alguno de esos ficheros en el servidor. ¿Pero cuál?, ¿será tema de permisos?, ¿será que el acceso a disco en los nuevos servidores es superlento? Bueno, no queda otra que debugear esta función, el problema es que como solo nos pasa en producción no podemos meter un debugger interactivo como xdebug, así que nos tendremos que servir de un simple log como este:

Y revisando el log generado por una petición que ha presentado el problema vemos lo siguiente:

¡2 ficheros JS que se están intentando empaquetar provienen no de un fichero local, sino de una llamada http!. En este caso la llamada http va contra nuestra propia máquina en un subdominio donde estamos sirviendo los ficheros estáticos para optimizar el rendimiento del frontend. ¿Y cuál es el problema? Este:

Resulta que los propios servidores no son capaces de acceder por http a sí mismos. Esto es lo que provoca el bloqueo y los tiempos de espera hasta que la función file_get_contents da un timeout.

La solución

Que los servidores resuelvan esa petición. Lección aprendida después de dedicar multitud de horas y recursos a intentar revisar el tunning del servidor, un profiling puede dar pistas de un problema puntual de rendimiento y ahorrar muchos dolores de cabeza como los que he tenido el último mes.

¡Gracias, xhprof!

Cinco sesiones destacadas de la Drupalcon Dublín 2016

Biko2 -

Un año más y gracias a la organización de la DrupalCon, he podido asistir a este fantástico evento que se celebró en Dublín.

Son días que pasan muy rápido porque son muy ajetreados: saludar a los amigos, asistir a sesiones, ayudar a otros mentorizando… Si cabe destacar algo, siempre digo lo mismo, es poder encontrarte con esos amigos con los que estás casi a diario colaborando y contribuyendo. Además, un año más me ofrecí como mentor para ayudar a otra gente a que se inicie a contribuir en el Core de Drupal. Siempre es un placer poder ayudar a otros

De todo lo que se habló en la DrupalCon, resalto cinco sesiones que me han parecido especialmente interesantes.

Destacaría como siempre la sesión de Morten sobre 21 things I learned with Twig & Drupal, una sesión con 260 slides contadas en 60 minutos. Rápido y directo, donde muestra multitud de ejemplos de los que aprender.

Una de las iniciativas más interesantes es la de e0ipso (Mateu) y Prestonso sobre la API First Initiative y la sesión de Mateu de Advanced Web Services with JSON API. Tuve la suerte de poder ver junto a Mateu el proceso y características de JSON API y algunas de las issue en las que estuve trabajando junto a él. Os dejo el vídeo de su sesión:

En cuanto a escalabilidad y rendimiento de entornos en Drupal la sesión de Fabianx de 4x High Performance for Drupal – Step by Step – The ultimate beginner’s guide me resultó muy clarificadora sobre qué cosas son necesarias tener en cuenta.

Una de las novedades en las que se trabaja es en LCache para futuras releases Faster and More Scalable than Memcache/Redis: Tiered Storage with LCache. No pude asistir a esa sesión, pero me resultó interesante conocer que existen novedades al respecto.
Os dejo el vídeo:

Por último, en cuanto a calidad de código y testear el código, comentaría la sesión de klausi y dawehner sobre Automated Testing: PHPUnit all the way en la que aparte de mostrarnos lo que existe actualmente, nos mostraron también las novedades que se van a incorporar en las futuras versiones.

Y sobre todo, lo mejor, encontrarte con los amigos drupaleros y contribuir al proyecto Drupal.

Cinco sesiones destacadas de la Drupalcon Dublín 2016

Biko2 -

Un año más y gracias a la organización de la DrupalCon, he podido asistir a este fantástico evento que se celebró en Dublín.

Son días que pasan muy rápido porque son muy ajetreados: saludar a los amigos, asistir a sesiones, ayudar a otros mentorizando… Si cabe destacar algo, siempre digo lo mismo, es poder encontrarte con esos amigos con los que estás casi a diario colaborando y contribuyendo. Además, un año más me ofrecí como mentor para ayudar a otra gente a que se inicie a contribuir en el Core de Drupal. Siempre es un placer poder ayudar a otros

De todo lo que se habló en la DrupalCon, resalto cinco sesiones que me han parecido especialmente interesantes.

Destacaría como siempre la sesión de Morten sobre 21 things I learned with Twig & Drupal, una sesión con 260 slides contadas en 60 minutos. Rápido y directo, donde muestra multitud de ejemplos de los que aprender.

Una de las iniciativas más interesantes es la de e0ipso (Mateu) y Prestonso sobre la API First Initiative y la sesión de Mateu de Advanced Web Services with JSON API. Tuve la suerte de poder ver junto a Mateu el proceso y características de JSON API y algunas de las issue en las que estuve trabajando junto a él. Os dejo el vídeo de su sesión:

En cuanto a escalabilidad y rendimiento de entornos en Drupal la sesión de Fabianx de 4x High Performance for Drupal – Step by Step – The ultimate beginner’s guide me resultó muy clarificadora sobre qué cosas son necesarias tener en cuenta.

Una de las novedades en las que se trabaja es en LCache para futuras releases Faster and More Scalable than Memcache/Redis: Tiered Storage with LCache. No pude asistir a esa sesión, pero me resultó interesante conocer que existen novedades al respecto.
Os dejo el vídeo:

Por último, en cuanto a calidad de código y testear el código, comentaría la sesión de klausi y dawehner sobre Automated Testing: PHPUnit all the way en la que aparte de mostrarnos lo que existe actualmente, nos mostraron también las novedades que se van a incorporar en las futuras versiones.

Y sobre todo, lo mejor, encontrarte con los amigos drupaleros y contribuir al proyecto Drupal.

Drupal vs Wordpress vs Joomla: 17 de octubre en Barcelona

Atenea tech - Blog -

El próximo lunes 17 de octubre, a partir de las 19h, realizaremos una charla que creo que es muy interesante: Drupal vs Wordpress vs Joomla

En esta charla contaremos con la presencia de Joan Artés, para defender Wordpress, Jorge Sala, en defensa de Joomla y Luis Ortiz y yo mismo que estaremos, obviamente, al lado de Drupal.

La charla tendrá una pequeña introducción de los tres CMS, y después, basados en unas características, hablaremos cada uno de los puntos fuertes y débiles de cada CMS. La idea es que los asistentes se vayan a casa conociendo mejor estos gestores de contenido, y sabiendo para qué tipo de web son más recomendados.

Realizaremos el evento en el Mobile World Centre, un espacio privilegiado en el centro de Barcelona que forma parte de una iniciativa público-privada creada por Mobile World Capital Barcelona (MWCB) y Telefónica.

Si os interesa, os podéis apuntar en este meetup: https://www.meetup.com/es-ES/wordpressbcn/events/234171853/

Os esperamos!

 

Suscribirse a Drupal Hispano agregador: Planeta Drupal Hispano