Posted by juan.medin on April 25, 2011 at 4:08pm
Artículo sobre los aspectos fuertes y débiles en Drupal y consideraciones a la hora de evaluarlo como una posibilidad frente a un desarrollo puro para el mismo fin.
Evaluando Drupal: Aspectos fuertes y débiles
Group categories
Región geográfica
- actualizacion (1)
- almeria (1)
- argentina (2)
- Asturias (1)
- ayuda (2)
- Barbate (1)
- barcelona (5)
- basque group (1)
- beach (1)
- Belize (1)
- Bilbao (2)
- Cádiz (1)
- Catalunya (2)
- ckeditor (1)
- cms (1)
- colaboracion (2)
- comunidad de madrid (3)
Comments
Buen artículo
Hola, Juan.
Buen artículo, estoy de acuerdo en prácticamente todo lo que comentas, pero en algunos aspectos añadiría puntualizaciones.
Por ejemplo, aunque es cierto que el rendimiento de Drupal es bastante mejorable, frases como "en un servidor de última generación, con un solo usuario y una única petición tarde más de dos segundos en generar una sola página no es nada extraño" pueden parecer algo sesgadas. Cuando un servidor potente y sin problemas de carga tarda más de dos segundos en generar una página, muy probablemente el problema esté más en un mal uso de Drupal (normalmente relacionado con el abuso de módulos o "modulitits" que suelen padecer los recién llegados al CMS) que en la propia plataforma.
Respecto a la personalización de las vistas, creo que el ejemplo de los foros no es el más representativo. En realidad personalizar una vista suele ser tan sencillo como añadir un preprocess() a tu template.php y crear la plantilla personalizada en tu tema. Los módulos forum, advanced_forum y comments son probablemente de los más problemáticos de todos los que me he encontrado en Drupal a la hora de añadir personalizaciones, por lo que no los consideraría el caso medio.
Termino con estas puntualizaciones (que espero sean tomadas como críticas constructivas) dándote las gracias y felicitándote por un estupendo trabajo.
Un saludo,
Carles.
Hola Carlos, Cualquier
Hola Carlos,
Cualquier crítica es extremadamente bienvenida.
La velocidad es lo que más me ha impactado de Drupal con mucha diferencia: acostumbrado a otros entornos me pareció extremadamente lento. Así como descubrir su arquitectura ha sido sensacional -y a la vez me ha hecho ganar un nuevo respeto hacia PHP y su comunidad de desarrolladores- creo sinceramente que el rendimiento no está a la altura.
En el caso de los módulos no sabría decirte si estábamos empleando demasiados. Lo cierto es que no se añadió ninguno 'por tener algo más' sino que la funcionalidad, de no haber estado disponible, hubiese sido necesario desarrollarla. Pero es posible que se pudiese haber prescindido de alguno a cambio de programarlo de una forma más eficiente para nuestro caso concreto a cambio de más tiempo de desarrollo.
De todas formas, algunas cosas que no implicaban pasar por todo el código o por los módulos era muy, muy lentas: una petición pura vía AJAX para leer una sola fila de una tabla com 5 elementos de prueba, con un sólo usuario en un servidor potente eran algo más de 400ms. Lo primero que se pensó fue: es evidente que algo está mal configurado. Pero parece que no, que ese es un rendimiento normal en Drupal.
Otro aspecto en su lentitud son los accesos a base de datos. Si tienes MySQL en otra máquina la latencia es un problema. En Java / .NET hay ya una cultura de desarrollo de pelear mucho, muchísimo para reducir el número de accesos (como es lógico). En Drupal tener más de 100 es algo habitual (e incluso un buen escenario). Por ejemplo, en el caso del módulo 'advanced forum', en su versión actual de desarrollo con 30 comentarios por página son más de 700 accesos (no está mal escrito).
Se une a la gran lentitud de PHP -frente a otras opciones típicas de desarrollo-, un proceso de bootstrapping enorme y un número de accesos a la base de datos demasiado alto.
Sobre elegir el foro, tienes razón, no tiene nada que ver con las típicas plantillas de una página normal, que son mucho más sencillas de desarrollar. El caso es que en los tres proyectos de Drupal siempre he tenido que tocarlo y parecía un caso de uso realista de lo que implica personalizar un módulo para adaptarlo a las necesidades del cliente.
Un saludo,
Juan
Sí, AJAX y Drupal se llevan
Sí, AJAX y Drupal se llevan fatal. Cualquier petición levanta un BOOTSTRAP_FULL, aunque sea una petición AJAX, cuando probablemente sólo necesitemos una pequeña consulta a la base de datos. Estaría bien poder controlar el nivel de bootstraping para cada petición.
Lo del exceso de consultas en el acceso a foros lo pudimos comprobar cuando vimos que en determinadas páginas de un site, la carga excedía de 8 segundos. Nuestra solución (que mucha gente no apoyará) fue reescribir los módulos de foros casi de arriba abajo, añadir almacenamiento estático, mejorar algunas consultas y aligerar el número de consultas lo más posible. A parte de esto cometimos muchos errores como instalar todo módulo que nos parecía interesante.
En sites concurridos, Drupal puede ser un problema debido a la baja calidad de algunos módulos y a su flexible sistema modular. Nuestro equipo de desarrollo tuvo que dejar de desarrollar y ponerse a estudiar mejoras durante un mes a causa de estos problemas. Escribí hace poco un wiki sobre optimización con muchas obviedades pero que quizá sirva a otros de ayuda.
A pesar de todo esto, pienso que para la mayoría de casos es un CMS muy aceptable, versátil y de desarrollo rápido.
El problema de foros nosotros
El problema de foros nosotros lo resolvimos sacando los foros a smf, y no veas si se noto ;)
Oskar
Con respecto al tema AJAX te
Con respecto al tema AJAX te recomiendo que le eches un vistazo a esto:
http://drupal.org/project/nodejs (hay un video muy interesante y revelador)
http://groups.drupal.org/node-js
http://groups.drupal.org/taxonomy/term/22528
eternos:
http://nodejs.org/
http://es.debugmodeon.com/articulo/introduccion-a-node-js
Se que developmentseed hace uso intensivo de node.js para sus herramientas de mapas.
Tambien se que los amigos de http://www.investic.net/ están investigando el tema, no se si tiene ya algo en producción, pero sería interesante montar una charla o un Bof en la drupalcamp de Sevilla para tratar el tema.
Creo que es una tecnología que merece la pena tener vigilada.
Un saludo,
Alessandro Mascherpa.
Nodejs es algo más que ajax,
Nodejs es algo más que ajax, es un framework de desarrollo y un servidor de javascript.
Implementar nodejs como solución de ajax (ahah en algunos casos) para Drupal no soluciona todos los problemas, ya que muchos módulos del core y contribuidos de drupal tiran de ajax no de js.
Y agregar nodejs significa meter otro servidor más a la máquina, y hay que recordar que dependiendo del proyecto a veces no se tiene acceso a esto y hay que trabajar con servidores compartidos.
Oskar
Posiblemente diferente escenario
En nuestro caso nuestras peticiones eran muy cortas en tiempo y no era necesario en absoluto procesarlas con eventos tipo node.js -aunque se levantasen hilos normales era totalmente satisfactorio-.
En concreto el usuario debería navegar por diferentes nodos y comentarios de forma fluída. El problema es la "clikinosis" de muchos usuarios, que les llevaba a hacer varios clicks rápidos para avanzar varias filas y a Drupal no le daba tiempo ni de procesar el primero :)
La solución fue añadir un pequeño servlet de Java con un pool de conexiones. El tiempo de ejecución que consumía era totalmente despreciable. Era velocidad pura, especialmente comparado con Drupal funcionando a su lado. Aunque este tipo de cosas (añadir varios servidores) suelen ser puertas al infierno, lo cierto es que funcionó muy bien y de una forma muy limpia. Fue necesario escribir una regla en Apache para redirigir las peticiones con un cierto path al servlet y sensacional. Nos permitió además añadir más peticiones desde el módulo.
Es cierto que era un caso de uso sencillo (nosotros controlábamos el módulo, no era necesario integrarlo con otros existentes) pero es que es una unión hecha en el cielo. Si alguien necesita peticiones prácticamente tan rápidas como es posible en AJAX, os animo de verdad a explorar este camino: es mucho más limpio de lo que parece.
Muy buen artículo
Estoy de acuerdo con todo lo expuesto en tu artículo.
Sin embargo he de decir que si hubiera leído tu artículo cuando me encontraba evaluando la opción de adoptar drupal para nuestros desarrollos me habría tirado atrás, o al menos me habría hecho replantearme la decisión. Me parece que en el artículo se incide mucho más en los aspectos negativos que en los positivos de Drupal.
En los puntos negativos que indicas los que realmente considero importantes son el de la velocidad y el de la curva de aprendizaje, pero más que cuestiones insalvables, considero que son puntos a tener muy en cuenta desde el principio del proyecto, para tomar las decisiones adecuadas antes de encontrarse con el problema.
Respecto al tema de velocidad, tal y como indicas, es realmente decepcionante ver como una instalación ligeramente compleja tiene unos tiempos de acceso inaceptables y no soporta una concurrencia mayor a 10 o 20 usuarios en una máquina normal. Sin embargo creo que intentando reducir al máximo el número de módulos desde el principio y teniendo claro el sistema de caché a utilizar, se puede salvar este problema y beneficiarse de todas las ventajas de Drupal. En proyectos medianamente importantes considero casi imprescindible el uso de Varnish, lo cual innegablemente añade una capa de complejidad al sistema, pero multiplica considerablemente el rendimiento de nuestro drupal. (Recomiendo que los que no lo conozcan investiguen un poquito sobre el proyecto pressflow).
Respecto a reducir el número de módulos, aunque es cierto que en ocasiones puede resultar que utilizar menos módulos reduce nuestra productividad, muchas veces es el desconocimiento del api el que nos empuja a buscar soluciones en módulos desarrollados cuando la programación de dicha funcionalidad específica es bastante rápida y optimizada. Esto nos lleva al punto de la curva de aprendizaje, la cual desgraciadamente solo se puede superar a base de horas y de pelearse mucho.
Yo creo, desde mi punto de
Yo creo, desde mi punto de vista que el problema de rendimiento en Drupal es y no es tan grabe.
Me explico, es cierto que Drupal básico es una herramienta lenta, pero igualmente es cierto que el núcleo de Drupal nos traen una cantidad de módulos que sinceramente no se que hacen en el core. Creo que la lectura del manifiesto de small core es necesario. No solo por la calidad del producto sino porque el mismo smallcore afecta también a la velocidad de Drupal, cuantos menos módulos tengamos instalados más rápido va Drupal.
Si no los vas a usar yo recomiendo quitarlos de la instalación, verás como la cosa cambia.
Uso y abuso de módulos, o el problema del "Buffet libre" de Drupal, he visto como "profesionales" de Drupal instalaban decenas de módulos y los configuraban (supongo que porque) es más cómodo configurarlos que hace un poco de trabajo con algunos módulos casi universales en Drupal como views.
2 ejemplos de esto.
Para poder enviar boletines de noticias bien en drupal tenemos que instalar entre 4 y 6 módulos. Con un poco de conocimiento se puede conseguir lo mismo con simplenews, views y nodereferene-views (incluso sin node referene views si queremos ser más puritanos) y un poco de programación en templates de drupal.
¿Porque usar blogs, y módulos que lo complementan si con views haces lo mismo? Y seguramente tendrás instalado views
Menos es más, menos módulos es más velocidad.
Por otro lado, algunas funcionalidades de Drupal, la utilización de otro idioma que no sea el ingles, no me refiero a multi-idioma, sino a tener Drupal en castellano, etc.... también supone una carga que tenemos arrastrar todas las instalaciones de Drupal menos las anglosajonas.
Los servicios de syslog, trancking, etc.. son un verdadero dolor para Drupal, solo de pensar que cada vez que un usuario pestañea Drupal lo guarda en la bbdd me quedo frio, no porque este mal hecho, sino por la simple cuenta de la cantidad de inserts que se ejecutan en Drupal. Si estos servicios se pueden sacar (Analytics, etc.....) Mucho mejor para Drupal, y módulos como cantidad de páginas leídas, votos, etc... que pueden ejecutar querys largas también son peligrosos.
Cuando se desarrollan módulos o temas en Drupal hay que tener en cuenta dos cosas que afectan también al rendimiento.
En temas, hay mucha gente que sigue metiendo código que no debe ejecutarse en los archivos *.tpl.php. Es cierto que Drupal no es un sistema MVC, pero así y todo, si respetamos estos principios la velocidad de Drupal también mejora, en los archivos *.tpl.php únicamente se deberían imprimir variables y ejecutar y if, el resto de elementos hay que meterlos en template.php o en un módulo desarrollado a medida.
Tampoco se deben cargar archivos de js o de css en los temas, por dos simples motivos, el primero es que no entra dentro del sistema de cache de Drupal, y el segundo esta llamada hace más lenta la carga de la página.
De temas también habría que ver los spites, y el código css, así como el html. Drupal general una cantiad de código html realmente innecesario, nosotros preferimos crear archivos *.tpl.php de cck para poder limpiar cuanto más mejor html,esto supone una mejorar en la carga de las páginas y una mejora en el seo también.
De módulos 3/4 de lo mismo, existen grandes programadores de Drupal, pero la cantidad de gente que se enfrenta y se pega con la api de drupal no es tan elevada, muchos prefieren crear/importar sus propias clases porque lo han hecho así siempre, duplicando muchas veces funcionalidades que ya hay en Drupal.
Por otro lado, hay casos que por desconocimiento o dejadez se obvian elementos básicos en la calidad del código, o directamente ni se ejecutan procesos de calidad antes de su implantación. El uso de cache, o de cache en bbdd no-sql es otro elemento de mejora importante, es verdad que los módulos de drupal trabajan con la bbdd de Drupal, pero los nuestros no necesitan de ello, y si vamos a almacenar mucha información cacheada es mejor plantear estas soluciones.
Leer la documentación de Drupal es duro, pero efectivo.
No puedo concluir sin dejar de hablar de comodidad vs velocidad.
Hay módulos (panels, views, display suit, organic groups, etc...) que por su naturaleza nos ayudan de una forma increíble a optimizar el tiempo que tardamos en finalizar una funcionalidad, pero dependiendo el proyecto hay que plantearse si estas herramientas son las más adecuadas o no. No es lo mismo 400.000 nodos que solo 100 o 1.000 nodos. No es lo mismo una web de noticias donde no hay usuarios autentificados que una redsocial, etc......
Creo que la velocidad de Drupal esta más relacionado con nuestro conocimiento de la herramienta y trabajar bien desde el principio que con la propia herramienta en sí, ya que sabemos que Drupal es lenta, bueno hagamos que sude para que se ponga en forma.
De calidad mejor me callo, porque he visto cosas que asustarían a los más valientes, años que llevo con Drupal :p
Oskar
Promovido al grupo Spanish
Todas las consultas técnicas se deben realizar en el grupo Spanish y opcionalmente en algún grupo geográfico de interés.
Gracias por su colaboración.
--
[develCuy](http://steemit.com/@develcuy) on steemit