Mes nouvelles activités ne me laissent que peu de temps pour mettre à jour ce blog. En attendant une éventuelle reprise de mes divagations éditoriales, vous pouvez toujours parcourir les anciens articles. A+ et bonne lecture!
Inéation
100% Drupal : Actualité, Documentation, Formation, Module, Thème
Une navigation par onglets pour votre site Drupal avec le module Quick Tabs
Après plusieurs articles sur les thèmes et quelques techniques évoluées, on va aujourd'hui revenir à des choses plus simples et découvrir Quick Tabs, un module qui permet de rajouter très rapidement des blocs de contenus multiples accessibles via des onglets (tabs). Les onglets sont un élément d'interface à la mode certes, mais lorsque ils sont utilisés à bon escient ils peuvent faciliter l'accessibilité de certains contenus.
Les onglets peuvent être utilisé sur la page d'accueil :
Ici, sur un site fictif traitant des CMS, chaque onglet donne accès au dernier article de chacun des CMS.
Les onglets peuvent être aussi utilisé pour les blocs de contenus :
Ici, sur le site de Le Monde.fr, 3 blocs de contenus à faible valeur ajoutée ont été réunis en un seul bloc.
Comme d'habitude, il existe plusieurs modules qui permettent de mettre en place des onglets. "Quick Tabs" est un des modules les plus complets et les plus performants. Il vient de passer en Release Candidate 2 pour sa version 2.0 et devient donc un module à considérer si l'on souhaite utiliser des systèmes de navigation par onglet.
Quick Tabs permet de créer autant de blocs à onglet que l'on souhaite. Pour chacun de ces blocs vous allez indiquer au module les contenus que vous souhaitez réunir et rendre accessible via un onglet. Puis une fois le bloc à onglet crée, il vous suffira de l'assigner, comme n'importe quel autre bloc, à l'une des régions de votre thème pour afficher son contenu.
Le module propose deux méthodes pour charger le contenu des onglets. Soit les contenus sont tous chargé initialement et affiché lors du clic de souris, soit chaque contenu est chargé lors de son affichage via Ajax. Le choix de l'une ou l'autre dépend de vos besoins et de la taille du contenu des onglets. Personnellement j'utiliserai Ajax pour afficher des contenus conséquents et éviter une charge trop importante lors de l'affichage initial de la page.
La plus grande force de Quick Tabs vient des options à votre disposition pour sélectionner les contenus de votre site. Ainsi chaque onglet pourra afficher le contenu d'un d'un noeud particulier, de blocs existants et même d'un bloc à onglet précédemment crée.
Voici quelques exemples de ce que vous pouvez créer en quelques clics de souris :
- Un bloc à onglet "A la une" pour la page d'accueil qui affiche 4 onglets, chacun affichant le contenu d'un noeud particulier que vous souhaitez mettre en avant.
- Un bloc à onglet "Dernièrement" pour la barre latérale qui affiche 2 onglets, chacun affichant le contenu d'un bloc standard comme "Dernier commentaires" et "Derniers membres".
Mais là où le module prend toute sa puissance c'est qu'il peut aussi afficher le contenu d'une vue crée avec le fameux module Views. Autant dire qu'avec ces deux modules combinés, tout est possible. Quick Tabs vous offre même la possibilité de passer des arguments supplémentaires à la vue.
Voici à quoi ressemble, le formulaire de paramétrage d'un bloc à onglet :
Voila je vous laisse expérimenter avec ce module intuitif et très simple d'utilisation. Un petit bémol tout de même, il semble que Quick Tabs ne marche pas lorsque le cache des blocs est activé.
Il m'intrigue un peu ce module, l'affichage semble généré par hook_block sans définition particulière sur le mode de mise en cache du block en question. Je présume que le mode est donc celui par défaut (PER_USER), mais du coup que ce passe-t-il lorsque le contenu change ?
Les changements d'onglets semblent se faire par requêtes asynchrones, il se passe quoi si tu désactive le javascript ?
D'un point de vue général, je préfère tes techniques "avances" :-) utiliser des modules pour gérer des choses qui sont du domaine du thème, c'est ultra-casse-binette. Déjà côté perf cela implique des requêtes (ici sur la table quicktabs) pour que l'affichage se fasse, ce qui n'est pas le top, surtout lorsque tu as beaucoup d'authentifiés (même remarque pour les maudits modules views et panels). Puis en terme de lisibilité et de maintenabilité, le gars qui débarque sur un projet utilisant ce module va passer un bon moment avant de comprendre que ce n'est pas dans le thème qu'il va trouver sa réponse, là c'est du vécu... Enfin, c'est pas cool à déployer de préproduction à production ce genre de trucs, sauf à exporter la base ou les settings (même problème qu'avec CKK).
Donc module sympa mais je le préconiserais surtout pour un site perso ou alors j'en faucherais de gros bouts pour un usage pro :)
Salut,
"utiliser des modules pour gérer des choses qui sont du domaine du thème" Oui effectivement, je me suis fait cette remarque en rédigeant l'article. Néanmoins cet article s'adresse à des utilisateurs non experts dans ce cas Quick Tabs est un moyen simple de combiner des contenus disparates (views, nodes) dans un bloc à onglet. QT peut aussi être un moyen simple, grâce a son ui, pour un administrateur lambda, sans compétences CSS, de réaliser de nouveaux blocs.
"Donc module sympa mais je le préconiserais surtout pour un site perso ou alors j'en faucherais de gros bouts pour un usage pro"
--> encore une fois, je suis plutôt en ligne avec toi, même si je ne suis pas aussi catégorique que toi. Je pense que pour un site de taille modeste avec une fréquentation modeste (ce qui est le cas de 90% des sites), la solution sera largement acceptable.
En bref, sur le fond toutes tes remarques sont justifiées, tu es un utilisateur exigeant et tu mets le doigt là ou cela fait mal, maintenant il y a de nombreux cas ou un module comme QT pourra remplir sa fonction sans trop rougir de ses défauts.
Merci pour tes commentaires de grandes valeurs en tout cas.
On est d'accord, j'avoue que je suis un peu terrorisé par les WebAgencies qui font du Drupal sur des sites à gros tirages et qui n'ayant aucune compétence de développement font de l'assemblage de modules avec le résultat que tu imagines. Mes remarques ne s'appliquent donc que dans ce cas de figure, et pour moi, c'est ce type de site qui représente 90% de mon boulot :)
Oui, et pour être honnête je ne dispose pas de tes compétences de développeur, tes remarques sont précieuses et apportent donc un éclairage supplémentaire à ce blog.
Néanmoins, n'oublie pas que Drupal est utilisable à plusieurs niveaux, et ce blog s'adresse à l'ensemble de la communauté et donc beaucoup aux débutants.
Pour finir, il est aussi très important de faire comprendre à certains que le meilleur CMS du monde ne permettra jamais de faire fonctionner un site à très fort trafic en un clic de souris.
Tu me fais passer pour un ayatollah là :) Bien sur que jai conscience Drupal est aussi très accessible au débutant et encore plus aux non-développeurs. C'est même pour cela qu'on a inventé les CMS si je ne m'abuse ;-)
Pour finir, il est aussi très important de faire comprendre à certains que le meilleur CMS du monde ne permettra jamais de faire fonctionner un site à très fort trafic en un clic de souris.
Je pourrais "off-record" te citer des boîtes "très sérieuses" qui n'ont pas ta sagesse, loin de là :) Résultat, les sociétés "victimes" qui ont une très mauvaise image de ce "Drupal qui rame" alors que le "Joomla du voisin", lui marche très bien... Moi le seul message que je voulais faire passer, mais c'est aussi une question que je pose, je cherche encore mes repères dans le domaine, c'est "module qui joue sur l'aspect visuel = risque potentiel de performance".
Bonjour,
Tout d'abord merci pr ce blog qui est une véritable mine d'or (je pense notamment aux tuto vidéo sur cck etc.) !
Je suis nouvelle utilisatrice de Drupal pour un Intranet d'entreprise.
En tant qu'administratrice je souhaiterais créer des onglets à l'aide de Views (sachant que je ne "peux" pas ajouter de modules).
J'ai vu que l'on pouvait créer des views sous forme de page, bloc ET menu... mais cela reste encore obscure : "Menu" "Default Menu Tab"... malgré plusieurs essais je ne comprends pas bien comment cela fonctionne...
Par avance, un grand merci à ceux qui pourront m'aider !
Bonne journée
dans ta vue tu ajoutes ajoute une première page avec son accés dans un menu:
page 1
chemin : mapage
menu : une entrée de menu normale (Titre Mapage par exemple)
tu vérifie que tu accède bien à cette vue à partir du menu crée...
ensuite tu reédite la page 1 de ta vue:
chemin : mapage/tab1
menu : onglet de menu par défaut
il te demande élement de menu parent et tu choisi existe déjà
ensuite tu crée une page 2
pour la page 2 tu choisi:
chemin : mapage/tab2
menu : onglet de menu
ensuite tu crée une page 3
pour la page 3 tu choisi:
chemin : mapage/tab3
menu : onglet de menu
Tu testes...
en espérant que ça marche
pfx
Tout d'abord Merci Alexandre pour cet article, sinon il y a quelques semaines j'ai ajouté le module a un site web en cours de construction je précise que c'est un réseau social et que d'après les premières études et benchmarking il accueillera entre 2000 et 3000 visiteurs par jour (et entre 1500 et 2000 simultanée) là je commence serieusement à me poser la question n'y aurait-il pas un risque de ralentissement parceque plus j'avance sur le site plus je me dis que ca va être un sacré challenge pour optimiser au mieux les performances QTabs est-il une bonne solution dans mon cas sinon quelle autre alternative (views tabs?)
Merci
1500 connections simultannée ? Oui là il va falloir penser à optimiser les requêtes...
Pour un tel volume de donnée, crois-en mon expérience, tu oublies définitivement les modules Views, Panels et à fortiori QuickTab. CCK passe à la limite même si ce dernier rajoute des requêtes intercalaires pour accéder aux contenus des champs custom.
Pour Views, il se remplace aisément par une requêtes custom dans un hook_menu. J'ai un tuto dans le tuyau à ce sujet dont l'exemple de code est ici :
http://svn.arnumeral.fr/public/tutoriels_drupal/tutoriel_listes
Panels se remplace tout simplement par de bons templates qui feront les layouts de ton site. Là c'est du dev web classique.
Et pour Quicktab tu as plusieurs options :
- Si le volume de donnée par onglet n'est pas énorme et peu ou pas dynamique, tu as tout intérêt à utiliser créer via un module un bloc contenant tous les onglets (via DIV/css) et de faire la magie avec JQuery côté client. Le cache module fera le reste pour assurer tes perfomances.
- Si tu as beaucoup de données et/ou des requêtes dans les onglets, tu devras plutôt opter pour une approche type "Ajax" envoyant un jeu d'onglets "vides" définis en CSS, et les fonctions JQuery associées pour charger à la demande le contenu de chaque onglet. Il te faudra alors un entrée de menu générique de type /get_onglet/xxx qui renverra le contenu de l'onglet à la sauce JSON.
J'ai plusieurs Qtabs tout d'abord ca contiendra les indispensables Recents comments (en views custom template) bref rien de très spécial jusque là mais là ou ca se gâte pour moi c'est que je voudrais une approche beaucoup plus "dynamique" en affichant les 10 dernières news et 10 upcoming news (façon digg it) avec full pagination en Ajax biensûr de ce côté là le chargement se fera en Ajax
Sinon j'utilise pas panels je préfère l'approche la plus intéressante pour moi c'est à dire le templating
Merci
PS : le lien est protégé par un pass http://svn.arnumeral.fr/public/tutoriels_drupal/tutoriel_listes
Oups, désolé
http://svn.arnumeral.fr/subversion/public/tutoriels_drupal/tutoriel_listes
Je ne suis pas trop d'accord avec le fait que QT ne sois pas valide pour cause de requete trop importante. Par default, le module utilise Ajax pour charger les tabs, ce qui a mon avis est un gain enorme de requete !
C'est aussi l'esprit Drupal de donner de la flexibilité par l'interface utilisateur. Quel est l'interet d'utiliser Drupal si on fini par coder la plupart des fonction et passer outre le systeme de modules ? Quicktabs permet de modifier des blocks en onglet, utilisant Ajax, sans ecrire la plus petite ligne de code. Si votre client veux changer quoique ce soit, QT rend cela extremement facile et flexible.
Désolé d'etre si defensif, mais j'ai beaucoup participé au development de ce module, et je trouve tres malheureux de lire qu'il soit reservé aux debutants. De tres gros sites drupal utilisent Quicktabs, comme http://www.spin.com/ ou http://www.theonion.com
Aucun besoin d'être "défensif" dans ton esprit en tout cas, car je ne trouve pas du tout ton commentaire agressif, bien au contraire. Je pense même que nous sommes d'accord sur les grandes lignes.
La seule chose que j'essaye de faire passer est que le choix des modules est crucial en terme de performances. Et qu'une fois que certains de ces choix ont été fait, il est très difficile de revenir en arrière. Cela ne visait pas particulièrement QT, mais tous les modules qui travaillent sur la couche présentation en général.
Je n'ai jamais eu l'occasion d'utiliser QT dans un de mes projets, je serais donc bien mal placé de juger ses performances. En revanche j'ai une vision beaucoup plus claire de Panels ou de Views. Et il est clair que plus le trafic augmente, surtout le trafic authentifié, plus ces modules sont pénalisant.
Maintenant il ne faut pas caricaturer, je ne suis à aucun moment en train de dire que ce genre de modules est "réservé aux débutants", je dis qu'il faut évaluer les performances de chaque module utilisé, que cette évaluation doit se faire face à un certains nombre d'estimations (nombre de connexions concurrentes max et moyenne, proportion authentifié/anonyme, etc.).
Je rajouterais que plus un site a du modules, plus il sera mécaniquement lent. C'est très vrai avec Drupal 5 (sur certains de mes sites, 120 modules consomme rien qu'en chargement prés de 30% du temps par pages authentifiées), un peu moins avec Drupal 6 (principalement grâce aux chargement à la demande des fichiers PHP associé aux entrées hook_menu les moins utilisées), encore moins avec Drupal 7 (via la code registry), mais cela restera toujours vrai. Et je ne parle pas des modules qui collent leur barda CSS/JS sans se préoccuper d'être utilisés ou pas.
AJAX est un gain énorme de requêtes
Oui et Non, beaucoup de clients posent en gras et rouge dans leur cahier des charges "Javascript doit être une option pas un pré-requis". Il n'est donc pas possible de se reposer sur AJAX pour optimiser le nombre de requêtes. Il ne faut pas oublier que dans pas mal de société, Javascript est désactivé sur les masters pour des raisons plus ou moins contestable de sécurité.
Maintenant même avec Javascript posé en pré-requis, AJAX n'est pas la panacée. Si cette technique peut réduire le nombre de requêtes, elle peut aussi induire de la latence. Dans le cas de figure d'une grappe de serveurs de base de données, sur un site fortement sollicité, il est plus rentable de faire toutes les requêtes d'un coup, de tout injecter dans une seule page et donc un seul paquet, de balancer le tout dans un tube compressé et de gérer les onglets en javascript. Et c'est encore plus vrai lorsque le cache Drupal peut être utilisé à plein. En AJAX chaque sélection d'onglet induira une latence lié à la charge IP, n'utilisera pas forcement le cache et induira un bootstrap supplémentaire, etc.
Mais là aussi tout est question d'usage, s'il s'agit d'un boite à onglet qui est très peu utilisée, on s'en fou.
C'est aussi l'esprit Drupal de donner de la flexibilité par l'interface utilisateur.
Je suis totalement d'accord sur le "aussi", ce qui implique "pas seulement". Drupal est aussi un fabuleux framework pour développer des sites, développer au sens "coder".
En somme mes commentaires ne remettent pas en cause la qualité ou les performances de ce module. Je dise seulement que plus les contraintes sont fortes, plus il est important d'évaluer chaque brique avec soin.
Merci pour ce commentaire detaillé. Il faudra que je me penche un peu plus sur les performances dans le future, non pas que je n'y pensais pas, au contraire, mais il y a peut etre des details que je pensait insignifiant sur lesquels il faudra que je me penche un peu plus consciencieusement.
Merci à vous deux, ce dialogue est très instructif. Y compris pour moi.
J'ai toujours eu du mal à voir comment on peut évaluer, lors de la construction d'un site Drupal, l'impact des modules que l'on va utiliser. Pourtant il est vital de savoir à l'avance si on va utiliser views ou si l'on va faire ses propres requêtes "a la mano". Cela a un gros impact sur le timing et le cout du projet tout de même.
J'aimerai bien savoir quelles sont les "bonnes pratiques" à ce sujet...
Vraiment de rien, je n'aurais pas voulu que tu penses que mon commentaire pointait sur la qualité de ton code ou de ce module.
Autre chose aussi, je suis un fervent défenseur de Drupal utilisable à deux niveaux :
Niveau 1 : "builder", on assemble les modules comme des briques Lego, on paramètre finement et on obtient un site dont les fonctionnalités sont très proches de celles rêvées par le client. Accessible aux non dév. qui maîtrisent parfaitement Drupal.
Niveau 2 : "developer", on code en s'aidant du framework (l'API) de Drupal et on est capable de répondre à n'importe quel cahier des charges même les plus sadiques ;-)
Dans la réalité, on doit avoir les parties à faibles VA bâties en niveau 1 et les parties très spécifiques ou soumises à des contraintes fortes en niveau 2.
Les bonnes pratiques je ne sais pas. Pour ma part je tire surtout cela de mon expérience. Cela commence par une évaluation sérieuse de la volumétrie. Avec Drupal il faut rajouter la proportion authentifiés/anonymes car le système de cache ne fonctionne (pour l'instant, D7 wait and see ;-) pas du tout pareil dans les deux cas. Ensuite de la volumétrie il faut tirer un planning de connexions concurrentes (de telle heure à telle heure, tant de connexions par minutes). A partir de là on est capable de savoir si le performances sont un facteur critique ou pas.
Après je liste les modules que je vais devoir inclure en catégorisant ceux qui sont des modules "admin" (gestion, cron, etc) et "contenu" (ceux qui jouent dans la création de la page). J'essaye de réduire au maximum les modules de seconde catégorie quitte à les alléger certains au moment du dev à la main et éventuellement les fusionner lorsque qu'il n'apporte qu'une chose très ponctuelle.
Pour Drupal, il y a trois phases critiques lors du chargement d'une page en Drupal. Le bootstrap (chargement des modules, etc.), le traitement de l'URL qui fourni le modèle de données, et le theming qui présente le modèle. Le temps de bootstrap augmente mécaniquement avec le nombre de modules activés. C'est d'ailleurs aggravé par des combinaisons diaboliques comme un stockage des fichiers sur un iSCSI ou NFS, et l'utilisation d'APC (les includes dans ce cas prenne prés de 3 fois le temps d'un chargement sur un FS local).
Ensuite je tente de déterminer par module le nombre de requêtes générées par pages. Et c'est là que je vois s'il y a un malaise au regard de la volumétrie.
Par exemple un site qui en 50% d'authentifiées et 100 connexions à la minute me génère en somme 200 requêtes par page, je sais que je vais avoir 100x50%x200 requêtes à la minutes, ce qui est un peu violent pour un MySQL de base, un peu moins pour un postgresql. Bref, là c'est une question d'arbitrage avec l'infrastructure materielle et logicielle.
Et si ça coince et que je peux pas réduire le nombre de module intervenant dans le theming, je les exclue du thème en passant par des requêtes à la main qui peuvent remonter plus d'information en une seule passe.
Par exemple si je dois afficher deux listes de nodes sur une front page sur un critère de type taxo, en utilisant views et panels j'ai au bas mot 5 ou 6 requêtes générées alors que je peux n'en faire qu'une seule remontant toutes les informations et formater cela dans mon thème à la main.
Après il est toujours possible de coller du cache custom ou du cache externe (http ou mysql) mais c'est toujours plus sain d'optimiser en amont que d'ajouter des usines à gaz de caches qui rendent le développement compliqué et les bugs difficile à remonter.
Voilà, on est loin d'une "best practice" mais c'est ma toutouille maison :)
Builder...Developer
J'aime bien ton découpage, je vais te le faucher si cela ne te dérange pas.
On est aussi d'accord sur la conclusion. Tout dépend évidement de l'envergure du projet, et surtout de la projection de cette envergure dans l'avenir, mais builder et developer sont aussi deux rôles auquel je rajouterais "infographiste". Pour réussir un site Drupal c'est difficile sans avoir dans l'équipe un développeur PHP chevronné, de même qu'un graphiste compétent. C'est d'ailleurs assez drôle car j'ai rarement vu un client qui imagine faire l'économie du graphiste, mais dés que l'on cause CMS, ils ont du mal avec le développeur. Et pourtant leur besoin est gavé de spécificités métier qui s'il n'est pas pris en charge proprement par un dev est repondu par un badaboum de modules.
Intéressante discussion (merci Alex d'avoir remonté sur Twitter !).
Ulhume, ton expertise m'intéresse (dommage que tu ne sois pas freelance, il y aurai du potentiel pour du dév Drupal - pour que le client s'intéresse au dév autant qu'au graphisme il faut un commercial qui sait expliquer comme il faut l'importance de ces deux aspects :P) et au risque de faire un peu de off topic par rapport à Quick Tabs (merci Alex je ne connaissais pas), je me demandai ce que tu penses du gain offert par memcache (le module drupal : http://drupal.org/project/memcache).
J'ai bien noté la remarque "Après il est toujours possible de coller du cache custom ou du cache externe (http ou mysql) mais c'est toujours plus sain d'optimiser en amont que d'ajouter des usines à gaz de caches qui rendent le développement compliqué et les bugs difficile à remonter."
Tout ça m'a l'air pertinent, mais cela impliquerai soit un dév sur mesure, soit une optimisation des requêtes utilisées par le module X ou Y, donc un coût non négligeable que le client n'est souvent pas prêt à assumer. Si je me fais l'avocat du diable, vu la baisse des coûts sur les serveurs, on peut se payer un dédié monstrueux pour bien moins cher qu'un dév spécifique visant à optimiser (ok, je serai le premier à dire que c'est très moche comme solution mais quand on vend, on doit aussi tenir compte de critère parfois pas très esthétiques et très économiques)...
Dans cette optique bassement économique des solutions comme memcache ne peuvent t-elles pas améliorer les choses ? Dans quel catégorie place tu memcache : usine à gaz ?
Je n'ai jamais été confronté à la problématique d'un site à très fort traffic, mais juste par curiosité car j'entend souvent parler de memcache chez les dév...
Pour Drupal, il y a trois phases critiques lors du chargement d'une page en Drupal. Le bootstrap (chargement des modules, etc.), le traitement de l'URL qui fourni le modèle de données, et le theming qui présente le modèle. Le temps de bootstrap augmente mécaniquement avec le nombre de modules activés. C'est d'ailleurs aggravé par des combinaisons diaboliques comme un stockage des fichiers sur un iSCSI ou NFS, et l'utilisation d'APC (les includes dans ce cas prenne prés de 3 fois le temps d'un chargement sur un FS local).
APC possède un paramètre (apc.stat) qui permet de supprimer les appels à stat() qu'il effectue à chaque requête pour vérifier si un fichier à changé ou non. C'est effectivement indispensable pour certains systèmes de fichiers (NFS, mais pas iSCSI, qui n'est pas un système de fichier et ne pose pas de problème) qui ne peuvent pas mettre en cache le résultat de cet appel.
Drupal 6 passe beaucoup mieux à l'échelle par rapport au nombre de modules que Drupal 5, grâce à l'inclusion conditionnelle que tu mentionnes. Pour Drupal 7, notre objectif est de s'assurer que tout le coeur ait une complexité de traitement presque constante (en O(1)) en fonction du nombre de module. C'est déjà presque le cas (le registry permettra à terme une inclusion conditionnelle de l'ensemble des fichiers, y compris des fichiers .module).
Ensuite je tente de déterminer par module le nombre de requêtes générées par pages. Et c'est là que je vois s'il y a un malaise au regard de la volumétrie.
Par exemple un site qui en 50% d'authentifiées et 100 connexions à la minute me génère en somme 200 requêtes par page, je sais que je vais avoir 100x50%x200 requêtes à la minutes, ce qui est un peu violent pour un MySQL de base, un peu moins pour un postgresql. Bref, là c'est une question d'arbitrage avec l'infrastructure materielle et logicielle.
Pour info, les deux serveurs MySQL absorbent 3000 requêtes par seconde, en moyenne sur une journée.
Par exemple si je dois afficher deux listes de nodes sur une front page sur un critère de type taxo, en utilisant views et panels j'ai au bas mot 5 ou 6 requêtes générées alors que je peux n'en faire qu'une seule remontant toutes les informations et formater cela dans mon thème à la main.
Généralement le temps de traitement total d'une page et la charge du serveur de base de données dépend assez peu du nombre de requêtes, mais de leur complexité et de la capacité de MySQL a les servir à partir de son cache de requêtes. Views est généralement très efficace (ie. la différence est difficile à mesurer par rapport à du code custom).
Son seul point faible est relativement technique, mais peut être important dans certains cas: Views génére uniquement des jointures gauches (LEFT JOIN), même dans les cas où un produit cartésien (INNER JOIN) aurait autant de sens et permettrait à MySQL d'optimiser l'ordre des jointures en fonction des caractéristiques des tables.
Après, quelque soit l'origine des requêtes, et si l'on recherche la performance la plus élevée possible, il est parfois impossible d'échapper à une dénormalisation de la structure des tables (par exemple par le biais de vues matérialisées générées automatiquement).
dommage que tu ne sois pas freelance
Ben si, justement :-)
Dans quel catégorie place tu memcache : usine à gaz ?
Non, pas du tout, et ça marche même très bien, sous réserve d'avoir suffisamment de RAM évidement. Faire du cache "per user" sur un support memcache cela me semble un peu limite, mais pour du cache de bloc ou de pages anonymes, c'est nickel. Et oui, ça améliore clairement les choses, c'est indéniable. Maintenant je ne l'ai testé qu'avec une installation Drupal 5 où il serait difficile de les empirer ;-)
Pour revenir à ce que tu disais sur l'aspect économique, je te suis à 100%. Maintenant les projets qui nécessite un dev c'est comme ceux qui nécessite un graphiste, généralement y'a le financement qui va avec. Pour les sites plus modestes, il n'y a pas non plus les mêmes contraintes de performances. En plus le développement custom, surtout pour la partie présentation, a un inconvénient majeur, le client y perd de sa capacité à faire vivre le site seul. Vu qu'il n'aura logiquement pas envie de payer quelqu'un pour par exemple modifier le layout de sa home, on est obligé de lui laisser la main sur un truc comme panels. Finalement cette histoire se règle d'elle-même sauf pour ceux qui veulent un site ultra-performant pour pas un rond, mais là c'est une autre histoire ;-) Moi le commercial qui me vend cela, je le suspend par les c** :)
APC possède un paramètre (apc.stat)
Yep mais ça aide mais pas des masses. Le problème posé vient des "include" qui deviennent très lents au point où un hack est sorti censé régler le problème (paramétre apc.include_once_override ) mais sans grand succès me concernant. Pour l'instant c'est tellement problématique sur une de mes installations que j'ai de meilleurs performances en désactivant APC qu'en le laissant tourner... Faut dire qu'il y a 120 modules en Drupal 5...
Pour Drupal 7, notre objectif
Notre ? Tu bosses sur cette partie du core ? Intéressant à savoir :)
Pour info, les deux serveurs MySQL absorbent 3000 requêtes par seconde, en moyenne sur une journée
De quels serveurs parle tu ? Combien de CPU par bécane, type de disque, etc. 1500 requêttes par secondes et par machine donc. Moi je peux te dire que sur une dedibox v1 qui reste un choix de prédilection pour beaucoup de petits clients, à 1500 requêtes les baies s'éjecte toutes seules des armoires ;-)
Plus sérieusement je ne cherchais pas à donner des abacles mais juste à expliquer ma démarche.
Généralement le temps de traitement total d'une page et la charge du serveur de base de données dépend assez peu du nombre de requêtes, mais de leur complexité et de la capacité de MySQL a les servir à partir de son cache de requêtes
Oui et non :) Oui car si merge deux requêtes en une seule tu ne gagnes au fond qu'un temps d'appel à la base. Ce qui est peanuts au regard du traitement. Mais non car tu fais ce merge dans l'idée, ce n'est juste pour remonter cette information d'un coup, c'est aussi pour ne faire ni appel à views (4 requêtes dans mon exemple), ni à panels (1 requête). Et là j'ai du mal à croire que tu n'as aucun gain.
par exemple par le biais de vues matérialisées générées automatiquement
Ton idée m'intéresse mais je n'ai pas trouvé de vue materialisées sous MySQL. Tu passes par des procédures stockées ?
C'est exactement ce que j'ai en tête:
En plus le développement custom, surtout pour la partie présentation, a un inconvénient majeur, le client y perd de sa capacité à faire vivre le site seul
Le choix d'utiliser Views ou Panel est aussi lié à l'autonomie que cela laisse à l'admin. Principalement sur des pages d'accueil, de sections ou certains blocs.
Certains gros sites ont fait ce choix, surement au détriment de la performance pure (avant cache ou tuning hardware).
Ulhume, tu n'as jamais pensé à contribuer au core (ou views ou panel) sur cet aspect là justement ?
C'est quoi le cache des blocs ? que je n'aille pas l'activer ;o)
Merci pour tout ces tutos qui me font avancer assés rapidement.
Bonjour.
Derrière remy_ventoux se cache un débutant Drupal qui apprend en autodidacte et qui reste faciné au quotidien par la silhouette de son voisin du Nord (Comprendre le mont ventoux).
Merci donc à tous les contributeurs de ce site riche en information
Au vu de ce que j ai lu, Quicktab a l air de correspondre tout à fait à mes besoins d ergonomie. (Je suis dans le cas d un site à faible taux de visites et ne suis pas gêné à priori par les problèmes de performance. Donc j essaie simplement de faire fonctionner QuickTab et je n y arrive que partiellement.
J ai :
- Créer deux contenus de type page que je souhaite visualiser sous forme d onglets dans une autre page
- Créer un bloc QuickTab avec deux onglets de type Node adressant les deux pages crées
- créer une troisieme page sur laquelle j espere les onglets
Tout marche, sauf que mes onglets sont vides comme si je ne liais pas correctement les nodes.
Je fais certainement une faute de debutant quelque part
Une idée ???
Meci
Trikapalanet Il faudra que je l'essaye, je l'ajoute à mes bm en attentand. Xevonaute
Black Hattitude
Cela me paraît très intéressant !
Xbox Live
SuperRefman