Mon avis sur le livre de C. Roudet et recherche d'avis sur les performances de D6

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,

je poste ici, sur l'invitation de Cyprien Roudet (auteur d'un livre en français sur Drupal 6 qui vient de sortir), les parties les plus importantes d'un email que je lui ai adressé dernièrement. Il s'agit d'un commentaire critique (je l'espère constructif) de son livre, et d'une demande d'avis concernant la qualité du code et les performances générales de Drupal 6, compte tenu de ce que j'ai pu lire ici ou là. Ce post a bien évidemment pour but d'élargir le débat à d'autres personnes. (PS: navré pour les sauts de ligne hasardeux).

(...) Étant actuellement en train de rechercher le CMS le plus adapté à mes besoins (...), j'ai trouvé pas mal de réponses à mes questions dans votre ouvrage. Un grand merci, donc. Je regrette cependant quelques petites absences ; je vous en fais part car je me dis que ça pourra peut-être vous servir pour une prochaine édition, ou peut-être pour alimenter votre site.

- premier point : il manque, dans ce livre comme ailleurs, une présentation simple, claire et globale des fonctionnalités de D6. Par exemple sous la forme d'un tableau synthétique tel que celui-ci, pour Typo3. Je trouve que ce serait un outil d'aide à la décision assez précieux (cette page de drupal.org n'est pas des plus pratiques pour se décider, vous ne trouvez pas ?). Les sites comparatifs tels que cmsmatrix montrent vite leurs limites...

- plus particulièrement, rien ou peu de choses sur le multilinguisme, alors que c'est une des nouveautés de Drupal 6 et un des points forts de ce CMS par rapport à WordPress ou Joomla!, qui ne le gèrent pas nativement (et qui le gèrent apparemment assez imparfaitement surtout quand on veut aller un peu au-delà du simple blogging ou du site vitrine). Ce point me semble assez important car Drupal peut s'avérer, notamment pour cette raison, une précieuse solution intermédiaire entre ces CMS et (le plus difficile d'accès encore, selon moi) Typo3.

- dommage aussi que la découverte du potentiel de structuration de contenus de Drupal n'aboutisse pas à une démonstration plus... intéressante dirons-nous (...). Pourquoi passer tant de temps à indexer du contenu dans des champs spécifiques, à "jouer" avec la taxonomie, si c'est seulement pour faire une liste de recettes dont on peut trier l'ordre d'affichage selon trois ou quatre critères ? Je ne suis pas certain que l'intérêt particulier de Drupal par rapport à Joomla! sur ce plan - tel que je crois le deviner en tout cas - soit mis suffisamment en évidence. Je ne suis pas certain que l'essai soit transformé, si vous voulez, alors que j'ai bien l'impression qu'il y a matière.

- il manque peut-être également une dimension utilisation dans un cadre commercial concret, sous la forme d'une boutique en ligne ou d'un magazine web avec abonnement... Mais peut-être avez-vous fait les frais de la lenteur des mises à jour des modules de drupal...

- enfin, mais je comprends parfaitement qu'il soit fort peu aisé de faire de la vulgarisation dans ce domaine, votre livre parle peu des performances (requêtes, consommation de la bande passante, etc.), au regard de la concurrence, ou dans l'absolu. J'y reviens tout de suite, un peu plus bas.

Mais en définitive, je le répète, ça reste un ouvrage rare, bien fait et donc précieux pour moi, comme sans doute pour bien d'autres.

Ceci étant dit, je reste sur la réserve quant à l'adoption de Drupal, précisément (j'y reviens) pour des raisons de qualité de conception et de capacité à supporter un trafic assez important de Drupal (disons environ 10-15.000 visites par jour), indépendamment de la qualité de l'hébergement bien sûr. À rebours des analyses partisanes () ou pas forcément ()
mais globalement très positives, j'ai découvert les propos d'un informaticien, "iAPX" (voir ses interventions sur
ce forum
, puis sur
son blog
, voir aussi par là), qui dit avoir eu l'occasion d'étudier le code des versions 4.7 et suivantes, et qui est pour le moins très inquiétant. Au point que sur le forum mentionné, la solution Drupal a vite été écartée par une personne demandant des avis sur les CMS du moment.

Je me pose beaucoup de questions après avoir lu ses propos. Je sais que
Drupal est une solution adoptée par de nombreuses entreprises importantes et réputées sérieuses (on en parle beaucoup ici, sur le blog [de Dries Buyaert], mais vous le savez sûrement !), y compris via des SSII de type Smile.
Toutefois, ses remarques semblaient fondées. iAPX a mentionné notamment des failles (failles de sécurité XSS et CSRF, pour être précis) qui se trouvent avoir été traitées dans le cadre du passage à la version 6.4. De
quoi se gratter le crâne, à tout le moins...

[Ajout : Un développeur Drupal, créateur de drupalmodules.com, reconnait également que Drupal 6 lance beaucoup de requêtes (Source : http://blamcast.net/articles/drupal-hosting )]

Toute cette seconde partie (...) sur la technique vise in fine à vous demander votre propre sentiment sur les propos de cet informaticien : d'après vous, Drupal (y compris Drupal 6.4) est-il un tel cauchemar au niveau de la qualité de son code et de ses performances avec des modules ? Pour poser la question autrement, Drupal n'est-il pour l'heure qu'une solution viable pour les entreprises qui ont les moyens de faire vérifier et optimiser par une équipe de développeurs "maison" le code de Drupal et de ses modules, avant implémentation ? N'étant pas informaticien mais plutôt
"communiquant multimédia", vous comprendrez que je souhaite m'assurer de la qualité des fondations de l'entreprise que je tente de monter...
Bien cordialement,

Version de Drupal : 

Il est assez intéressant de voir ce qu'un mélange d'incompétence et de mauvaise foi peut créer.

Je ne vais pas m'amuser à répondre point à point à ses affirmations. Il suffit de savoir que Drupal sert à l'hébergement de sites à gros trafic, offre une qualité de code sans égale (le processus de revue de code est particulièrement bien rodé), ainsi qu'une flexibilité et une adaptabilité qui est loin d'être égalée par la plupart des concurrents, libres ou propriétaires.

Evidemment, Drupal s'appuie beaucoup (dans sa configuration standard) sur sa base de données. Cela permet d'installer Drupal partout sans aucun problème (sur n'importe quel hébergeur PHP/Mysql, par exemple). Les sites à fort trafic ont des besoins différents et déploient des solutions qui permettent de décharger la base de données (cache en front-end, memcache, etc.). Les solutions existent et sont bien documentées. Les technologies déployées dépendent évidemment de la taille du site (ie. une mobylette n'emploie pas le même moteur qu'un supersonique).

Concernant la sécurité, Drupal s'est doté d'une politique très volontariste dans ce domaine, assez bien décrite sur la page de l'équipe de sécurité. Pour une comparaison des approches en terme de sécurité des différents CMS opensource, voir aussi cette analyse.

Évidemment, ma vision est particulièrement partiale. Je suis contributeur de Drupal Core depuis des années, et membre de l'équipe de sécurité.

Ceci étant dit, je reste sur la réserve quant à l'adoption de Drupal, précisément (j'y reviens) pour des raisons de qualité de conception et de capacité à supporter un trafic assez important de Drupal (disons environ 10-15.000 visites par jour), indépendamment de la qualité de l'hébergement bien sûr.
AMHA faire un site Drupal qui tienne un fort traffic requiert plusieurs competences qui ne dependent pas seulement de l'expertise de Drupal...

Il est tres facile pour un developpeur de creer un site Drupal avec des tonnes de modules qui reponde au cahier des charges, sauf qu'une fois le site cree il faut prendre en compte l'architecture de son hebergement.
En gros oui Drupal genere des tonnes de requetes (c'est le probleme des fonctionalite -aka je rajoute un module en 2 clics- contre les performances), mais le simple fait d'activer le cache fait qu'une page qui se genere en qques dizaines de requetes ne fera plus qu'une seule requete au niveau de la BDD.

Cependant, pour faire qu'un site tienne la charge il faut qu'une personne s'occupe de customiser Apache, MySQL et PHP afin d'afiner les reglages necessaires, installer un cache PHP (opcode), plusieurs serveurs Apache et/ou MySQL etc...
Ceci n'est generalement pas une competence a la portee du premier "webmaster" venu...

Mais bon pour faire rapide, on pourrait citer de nombreux site a tres tres gros traffic developpes avec Drupal:
http://myplay.com/
http://www.theonion.com/content/index
http://buytaert.net/popular-science-using-drupal
http://buytaert.net/fast-company-using-drupal
Et j'en oublie surement des kilos tonnes

Sinon pour terminer sur la partie optimisation du serveur,
http://2bits.com/articles/can-a-drupal-web-site-handle-a-million-page-vi...
http://2bits.com/articles/drupal-performance-tuning-and-optimization-for...
Je pense que ca repond a ta question ;)

Oui, sans être un développeur, je suis convaincu du fait que l'hébergement et divers réglages périphériques (par rapport à Drupal) ont leur importance; je n'exclue d'ailleurs pas du tout de faire appel à un développeur pour effectuer les réglages en question le moment venu. Ce dont je voulais m'assurer, c'est que Drupal n'était pas comme un enfant de 3 ans que je mettrais dans une formule 1. Je caricature, bien sûr, mais en gros telle est l'idée. Merci pour tes liens.

Le probleme serait plutot de savoir qui est l'enfant de 3 ans et qui est la formule 1...
Perso j'aurai tendance a dire que le dev serait plutot l'enfant de 3 ans qui serait completement ebloui par les tonnes de modules et en activerait 3 tonnes sans penser a l'impact que ca aurait sur le serveur le jour ou il y aura plus de 10 visiteurs simultanes...

J'ai pas releve les remarques faites par le blogueur qui critiquait que la BDD de Drupal etait ecrite avec les pieds mais bon je vais juste faire 2 remarques:
- For example Users and Profiles. When you retrieve and User, you generate one SQL query. If you need it's Profile informations, you generate ANOTHER query. 2 Queries to have an user informations, yes! le fait par exemple d'avoir une table profile sur laquelle tu fais une query a part celle des utilisateurs rejoins exactement ce que je disais concernant la flexibilite du bazar. Evidemment si t'as le control total de ton applis, tu preferas coller le profile directement ds la table de l'utilisateur sauf que Drupal est concu pour etre modulaire, donc si t'as pas besoin de profile, ca sert a rien d'encombrer ta table d'utilisateur avec 24000 champs inutiles...
Le monsieur iapx a surement des besoins bien plus avancees que 95% des sites construits avec Drupal (replication de BD & co), mais il faut savoir que Drupal evolue sans cesse et la v7 prendra en compte les replications ;)
Apres il a l'air de coder des sites tellements particuliers que de toute facon ils seront jamais fait avec n'importe quel CMS...
Pense juste a tes besoins et le tps que tu passerais si tu devais developper ton site "from scratch" et surtout qui serait capable de reprendre un developpement maison...
- derniere remarque, c'est bien beau de critiquer Drupal, mais apparement (a moins qu'il ait pas utilise le meme nom d'utilisateur), il a travaille un certain tps avec Drupal, mais n'a jamais soumis aucun patch pour ameliorer les choses... La critique est facile...

La "parabole" de l'enfant de trois ans dans la F1 peut être effectivement mise à plusieurs sauces. Pour reprendre ta version, je tiens quant à moi à être le moins "enfant" possible face aux fonctionnalités de Drupal (car le risque me semble particulièrement élevé lorqu'on n'est pas développeur). Je sais que j'ai un outil puissant et flexible, mais qu'on ne peut pas faire n'importe quoi avec ; je sais par exemple que l'ajout de modules n'est vraisemblablement pas neutre en terme de nombre de requêtes SQL. J'ai aussi l'intention de me former davantage pour être encore un peu plus "adulte" et responsable face à la mécanique Drupal.

Ta réponse m'amène à entrevoir que cet informaticien n'avait pas complètement tort ; il y aurait bien un nombre important de requêtes, bien que ce soit pour des besoins de modularité. Ceci étant dit, ça ne remet pas en cause la valeur de Drupal, bien au contraire, et ça change pas mal de choses pour moi. Ses propos m'alertent donc sur la quasi nécessité d'une optimisation de la bdd. On rejoint là mon interrogation sur Drupal comme outil à la portée des petites PME ou plutôt pour les grands comptes, qui peuvent se permettre une customisation du code par x développeurs...

Quant à l'implication de ce monsieur iapx dans le projet Drupal, hmm sans vouloir le défendre plus que ça (je ne le connais pas), si il a un client au-dessus de lui, il ne peut peut-être pas se permettre ce genre de choses. C'est un peu comme les clients qui refusent que les développements qu'ils font faire sur la base d'un CMS Open source soient mis dans le pôt commun...

Sinon, sans vouloir abuser, aucune idée pour cette demande ? À défaut, je me demande si je ne vais pas plutôt opter pour Drupal 5...

Ta réponse m'amène à entrevoir que cet informaticien n'avait pas complètement tort ; il y aurait bien un nombre important de requêtes, bien que ce soit pour des besoins de modularité.

Le problème c'est que la métrique elle même est très limitée. Le nombre de requête n'a jamais été un bon indicateur de performance d'un site. Drupal exécute effectivement de nombreuses petites requêtes pour satisfaire facilement ses besoins en terme de modularité, mais ces requêtes sont généralement d'une très faible complexité (ie. récupération d'une ligne sur la base d'une clé primaire, dans une structure en étoile autour d'une table pivot). Faire deux requêtes peut ainsi réduire la complexité du code et faciliter sa maintenance, sans impact sensible sur les performances.

Evidemment, activer un grand nombre de module augmente la taille du code chargé (et donc la mémoire nécessaire), ralenti l'exécution, augmente le nombre de requêtes, etc. Mais c'est la contrepartie naturelle lorsque l'on charge trop la barque en terme de fonctionnalités. Notez néanmoins que, à partir de la version 6, Drupal charge les modules de manière intelligente : il va essayer de charger le seul code dont il a besoin pour afficher une page donnée. Et cela s'améliorera encore avec Drupal 7 (en cours de développement).

Quant à l'implication de ce monsieur iapx dans le projet Drupal, hmm sans vouloir le défendre plus que ça (je ne le connais pas), si il a un client au-dessus de lui, il ne peut peut-être pas se permettre ce genre de choses.

L'explication est moyennement bonne. Les deux tables qu'il a repérées (authmap et access) pourraient en effet être mieux indexées (même si l'impact est très limité en pratique). Il suffisait pour cela d'ouvrir un ticket sur drupal.org, pourquoi ne l'a-t'il pas fait ?

Merci de ces précisions, plutôt rassurantes. Je trouve que cette histoire de modules est à la fois un atout et un talon d'Achille. Je m'étais fait la réflexion lorsque j'avais un blog WordPress, il n'y a pas si longtemps. WP est un "CMS" réputé pour sa fiabilité, mais les plugins proposés parallèlement sont généralement sans garantie d'aucune sorte, même si globalement je n'ai pas rencontré trop de problèmes avec. Il manque je trouve une sorte de système de labellisation des add-ons, assorti de précisions sur l'impact possible de l'utilisation de tel ou tel add-on. Je me doute que la chose n'est pas simplissime, notamment le fait d'assurer la bonne compatibilité des add-ons entre eux, mais je reste convaincu qu'il y a là une piste d'amélioration à creuser. C'est en tout cas évident s'agissant de WP. Mais bien sûr, me répondrez-vous peut-être, le premier talon d'Achille, c'est l'utilisateur qui s'avère incapable de vérifier si un code est bon ou pas...

"Le nombre de requête n'a jamais été un bon indicateur de performance d'un site."
Je serai assez preneur d'informations sur les bons indicateurs de la performance d'un site. Par hasard, aurais-tu un ou deux liens à me proposer sur le sujet ?

Et pour notre iapx, j'ai bien pensé à l'inviter à une discussion par ici, mais je ne pense pas que nous soyons vraiment en terrain neutre ; je ne veux pas provoquer une lapidation collégiale de ce monsieur, quels que soient ses torts éventuels ;-)

En aparthee, je veux pas faire le proces du iapx, je souhaitais juste faire remarquer que c'est facile de critiquer un systeme, mais si tu bosses avec et que tu prends meme pas la peine d'ouvrir un rapport de bug pour signaler un gros pb de perf que tu as decouvert et pour lequel tu viens d'ecrire 1 page de ton blog, c'est vraiment pas cool.
Apres il m'est sympathique car chui en train de me taper son blog depuis une demi heure :D

Je suis tout a fait d'accord sur le fait que les modules soient la force et le talon d'achille de Drupal (et a mon avis de n'importe quel systeme modulaire, FireFox pour ne pas le citer...)
Donc le but du jeu est que le dev soit conscient de ces problemes et capable d'auditer la BDD et surtout de trouver des solutions pour remedier aux eventuelles lenteurs.

Si par exemple il manque un index sur une table, ca prend 30s a creer et ca se diagnostique facilement via le MySQL Slow Query log http://dev.mysql.com/doc/mysql/en/Slow_query_log.html

Une bonne connaissance des mecanismes de caching de Drupal aidera aussi grandement...

Bref un site tout simple sur Drupal c'est a la porte de quasiment tout le monde, une fois que le site devient populaire, il faut penser a optimiser l'architecture qui est derriere et c'est un autre metier.

Tiens je te rajoute un peu de lecture:
http://buytaert.net/drupal-in-the-cloud
http://drupal.org/node/2601
http://books.tag1consulting.com/scalability c'est une boite de consultant en "scalability" specialise en Drupal, donc si t'as vraiment un pb tu peux trouver de l'aide :D

Ah ! Et bien j'arrive un peu tard :)
Donc, voilà ce que j'avais répondu par mail :
Concernant les manques dans mon livre : Oui, ce sont des sujets intéressants à traiter, mais je ne pouvais pas tout traiter. De plus certains modules n'étaient pas encore disponibles au moment de l'écriture.
Sinon, pour les critiques sur Drupal, je crois que j'étais pas trop loin de ce Damien et Tostinni ont dit :
1 - Drupal est reconnu pour la qualité de son code
2 - Il est très facile de créer des modules
En contrepartie :
3 - Il existe un grand nombre de modules de qualités inégales, il faut donc bien les choisir pour le type de site que tu souhaite créer.
Bon courage !!!

Bonjour Cyprien,
Oui mea culpa, je t'avais prévenu que j'allais poster ici mon mail, mais je ne t'ai pas indiqué que c'était chose faite. Merci de tes réponses et de tes encouragements.