france.fr : Error 500 - Internal incompetence error ?
Normalement je n'aurais pas eu grand-chose à faire des mésaventures de france.fr qui s'est lamentablement cassé la binette, et en fanfare, le 14 juillet dernier, si ce dernier n'avait pas tourné sous Drupal. Et même sachant ça, cela n'aurait pas été un sujet non plus si depuis le crash, je n'avais pas entendu mille fois la tirade du "Normal, c'est du Drupal, donc ça broute", déclinée dans tous les styles (spipien, wordpression, j'en passe, et des moins mûres).
Les chiffres
Pour commencer, je n'ai aucune idée de la manière dont ce site a été construit ni comment il fonctionne. C'est d'ailleurs fou le peu d'information que l'on arrive à glaner sur un projet financé à grand frais sur nos deniers. Pour ce que j'ai pu trouver, le site a coûté 800 000 euros, il a été réalisé par le société modedemploi (merci à Damien Leloup pour l'astuce qui m'a permis de le vérifier), une société très réputée dans le monde Drupal... et l'ensemble tournerait sur 12 machines (je n'ai pas réussi à trouver confirmation formelle de ceci).
En cherchant bien, nous avons malgré tout quelques informations. Cela commence avec une suprenante déclaration d'un responsable du gouvernement (au moins j'aurais appris qu'il y a des gens responsables dans ce gouvernement...) :
Déjà j'ai un peu de mal avec les imprécisions (ou noyage de poisson), car 25000 connexions pour une 1/2 journée (extrapolons donc à 50000 pour la journée entière du mercredi) ça veut dire quoi ? Ce sont des pages servies, des visiteurs uniques ? toutes les connexions (css, images, etc) ? Si ce sont des pages, cela me semble bien peu, et si ce sont des visiteurs uniques, ce n'est pas beaucoup plus brillant.
Sur France Intox, l'extrapolation à 50000 est confirmée par le directeur du SIG :
Déjà j'aime beaucoup le concept de "surprenante affluence" de 50000 visiteurs (uniques j'imagine) pour un site web international, qui représente la France, ouvert un 14 juillet, en pleine période touristique. ici le tragique flirte avec un comique qui ne va pas améliorer le moral lorsque nous recevrons notre prochain appel d'impôt.
Maintenant pour moi la notion de "visiteur unique" est sûrement très intéressante pour la mesure d'audience, mais n'a aucun intérêt d'un point de vue technique. A cet indicateur je préfère le nombre de pages servies par minutes et par serveur. J'ai constaté que pour un site de contenu, à un visiteur unique correspond en gros en moyenne 4 pages servies (je subodore que ce soit bien moins important pour france.fr, chiffrage optimiste donc).
Donc on peut imaginer que le site france.fr s'est étouffé à 200 000 pages servies par 12 machines pour la journée du mercredi 14 juillet, soit 11 pages par minutes et par serveurs (ppms)... Énorme, en effet... Sauf si les 12 bécanes sont en réalité un cluster de TO7 en nano-réseau rescapés du plan "Informatique pour tous", il y a comme un problème...
Éléments de comparaison
A titre de comparaison, et avant de parler d'inneficience de Drupal, Rue89 mange 2 millions de visiteurs uniques par mois avec seulement 4 serveurs. Ce qui nous donnes du 46 pages par minute et par serveur (toujours en prenant 1 visiteur unique = 4 pages). Donc déjà cela prouve que Drupal peut aller un peu plus loin que du 11 ppms.
Pour être plus objectif encore, j'ai fait un coup de cat/get/wc sur les logs apache de l'une des machines (la flemme de faire une agrégation tous les logs :-). Résultat : 175000 pages services en 24h, soit donc 120 ppms.
Conclusion
Mes calculs reposant sur une conversion un peu foireuse entre les nombres de visiteurs communiqués et la réalité des pages servies, ils valent ce qu'ils valent, c'est à dire pas grand chose. Cependant cela prouve tout de même qu'il existe des sites Drupaux qui tournent à un bien plus important régime avec bien moins de machines. Donc l'argument de l'inefficience de Drupal me semble un peu fallacieux. Qu'un Drupal brut de coffrage tourne moins vite qu'un SPIP je n'en doute pas une seconde, mais moins vite ne signifie pas obligatoirement beaucoup plus lent.
Ensuite si l'on cherche les causes possibles, nous avons déjà l'erreur de paramétrage de Drupal (genre "Oups, on a laissé le cache en base les gars, la boulette !!") ? J'en doute, cela aurait été réglé depuis une semaine que le site est HS. Nous avons aussi comme cause possible le grand classique du drupal super lourd gavé jusqu'à la trogne de modules boulimiques enquillés à la vas-y-que-je-te-pousse ? J'en doute aussi car ce site est totalement anonyme (à ce que j'ai eu le temps d'en voir). Cela veut dire que très rapidement l'ensemble des pages se trouvent compressées dans le cache frontal et servies sans requête SQL (et ce sans même sans compter sur un reverse-proxy comme Varnish). Et si les intégrateurs avaient oublié d'installer un truc aussi basique que memcache, en une semaine, je gage que cela serait tout de même déjà fait.
Reste la solution la plus simple, l'erreur sur l'architecture technique. Ce n'est en effet pas parce que l'on enquille 12 serveurs que le site va pédaler plus vite (ce n'est pas des rameurs que l'on peut ajouter pour aller plus vite ;-). Cela peut donc être une base de données sous-dimensionnée ou en MyISSAM (problème de lock) qui étoufferait les drupaux lors de la génération initiale des pages en cache, l'oubli d'un réseau privé entre les machines du cluster, etc, etc.
Bref, désolé pour les SPIP & Wordpress (que j'apprécie au demeurant), plein de raisons possibles, mais de par le profil purement anonyme du site, ce n'est clairement pas un problème de Drupal (ou alors les auteurs de ce site sont réellement des savates, ce qui n'est pas exclu).
Merci pour cette synthèse qui rassure quant à l'efficacité de Drupal. Aussi il serait peut être bien de faire un tuto pour les webmasters Drupal visant à indiquer quelles sont les bonnes pratiques pour optimiser Drupal tant au niveau de la gestion du cache que des points à surveiller pour servir les pages le plus rapidement possible.
J'ai souvent entendu parler de Devel qui permettait de voir le nombre de requêtes et le temps d'exécution pour chaque page, sans jamais trouver (ni vraiment chercher!) de tuto qui indiquerait les points à faire attention pour optimiser ses sites.
De plus en cas de site à fort traffic, quels serveurs prévoir, quels bases?..
Le problème c'est qu'un tuto n'y suffirait pas car les optimisations pertinentes sont très variables d'une situation à l'autre. Dans le cas de mediapart, ce n'est qu'une fois que j'ai eu les indicateurs en main que j'ai pu constater un 80% de trafic anonyme, ce qui m'a surpris pour un site de contenu payant. Du coup j'ai mis en place une stratégie basée sur ce constat et ça fonctionne nickel. Mais une autre situation aurait nécessité un autre schéma d'optimisation. La base étant cependant une gestion du cache obligatoirement en mémoire (ou en fichiers statiques avec boost), une base en innodb pour une meilleur granularité de verrous, et un regard particulier sur le ration connecté/anonyme et sur la fréquence de mise à jour des contenus. Sur mediapart comme exemple, le truc est passé en modifiant le module memcache de sorte à réduire la vidange du cache_page à une fréquence bien inférieur à la réalité de mise à jour des contenus.
Pour ce qui est de Devel, bof. C'est super basique. Le nombre de requêtes et la liste des plus gourmandes est une base, mais ce n'est pas suffisant loin de là. Perso je tourne avec un module custom qui va chercher une dizaine d'indicateurs à différents point du drupal (temps de construit des pages, nb et temps moyens des requêtes en lecture et écriture, nombre de requêtes en cache, taux de réussite (hit) du cache, nombre de hooks invoqués, temps de chaque fonction de thème appelé, etc).
Peux-tu nous en dire plus sur le module Memcache, sur les bases innodb (différences avec myIsam) et autres trucs pour optimiser?
Personnellement, quand j'augmente la durée de vie du cache, j'ai toujours un client qui me dit, quand je fais la maj, je ne vois pas les modif. Comment faire pour bien gérer le cache tout en voyant les modifs aussi?
Pour l'Histoire : le problème venait plus de l'hébergeur que des paramétrages et du code, même si ces derniers étaient loin d'être optimaux...
je n'ai pas vu le site , avant mais il y a aussi une hypotése ; Le site peut utilisé un grand nombre de vue avec des modalités importante , des node reference de partout etc... => des requetes mysql trés complexe, => crash du serveur mysql : j'ai rencontré ce probléme.
Ceci dit il ya des moyens d'optimisé ,d'ailleurs j'ai vu passé (pas testé) un module dédié à çà récement.
Un autre moyen de boosté un site drupal entre autres , c'est ngninx .
Je penche aussi pour un probléme d'architecture pas de CMS
PS autre exemple de site gouvernemental à forte charge : la maison blanche
Non désolé cela ne colle pas. Même si (sans offence) le site est construit comme un légo fou, il n'en reste pas moins pûrement anonyme (je n'ai même pas vu lorsqu'il fonctionait d'endroit où poster des commentaires). Du coup, il devrait être totalement en cache et le mystère reste donc entier.
Pour ce qui est de ngninx, honnêtemenet, gros bof. Si tu prends une architecture standard pour un site drupal à haute dispo, tu as un varnish en frontal qui cache tout ce qui peut l'être (css, images, contenu anonymes, etc.). A la limite on peut imaginer un lighttpd ou équivalent pour les resources statiques, mais à ce moment là il faut que ce soit sur un domaine séparé. Enfin pour tout ce qui est dynamique, c'est à dire dés que PHp rentre dans la boucle de réponse, ces serveurs lights n'apportent absolument plus rien en comparaison du temps passé dans l'interpréteur.
A moins qu'ils ne sachent pas ce qu'est un cache ou un CDN... En plus ca tombe mal tout le monde est en vacances, les appels d'offres ne vont plus se faire avant la rentree, bref la panique.
Bref l'epilogue de tout ca est que le site ne va pas revenir d'ici aout. Ca c'est completement hallucinant. Meme si le site est absolument pas optimise et rame meme avec une personne dessus, je comprends vraiment pas la difficulte d'aller sonner chez Akamai et de coller tout ca ds leur cache planetaire ???
Ca y est, tu es célèbre :
http://www.lemonde.fr/technologies/article/2010/07/23/france-fr-le-recit...
:P ;)
Après ces déclarations, de là à ce que le SIG vienne toquer à ta porte en te disant : "Puisque vous êtes si malin Monsieur et que tout cela vous fait sourire,..." Combien de jours pour l'optimiser, ce site ??? :P :D
Blague à part, je reste ébahie par le budget affecté (1.610.519,25 € TTC) et consommé (862.705 € TTC à date)... pour un tel naufrage. Devant ce gâchis, on ne peut s'empêcher de se demander comment les intervenants ont été choisis, quelles garanties ont été données sur leurs savoir-faires et compétences, si les bonnes pratiques ont été respectées (méthodos & Cie), etc.
Y a encore du travail à faire, hein, sur la question du contrôle des dépenses publiques !
@little
Ca y est, tu es célèbre
Ah bé voilà, maintenant je vais avoir des ennuis ;-)
Ceci dit, j'suis pas le seul que ça faitsourire à l'évidence
@Julie
Voilà je souris moins maintenant que je me rappelle que c'est avec les sous de bibi que ça a été payé tout ça...
Maintenant qu'il vienne toquer le coco, moi je pars en vacances !
Remarque c'est p'tet pour ça qu'il est pas relancé le site, ils sont tous allé faire des patés de sables sur la plage cette fois ;-)
La remise en perspective est utile. Cela dit, n'oublions pas que vu le type de site qu'est France.fr (majoritairement anonyme), l'ensemble doit pouvoir tenir sur un serveur unique, sans même avoir besoin d'un CDN.
Varnish peut servir environ 5000 pages/s/core. Ca laisse largement de la marge :)
Allez, on va dire deux machines pour pas que ça guru-médite de trop, c'est tout de même la vitrine de le Frannnnce ;-) Bref, on est tous d'accord, bras cassé land en somme. Et le plus fou dans cette histoire c'est d'imaginer que depuis maintenant bientôt deux semaines, ils sont en train d'essayer d'installer Varnish quoi :)
Ceci dit, on a peut-être pas toutes les données d'infrastructure, si ça se trouve, ils ont fait le choix de tout faire fonctionner sous Windows Server (j'ai toujours adoré cet oxymore ;-).
"fonctionner sous Windows Server" ..... Occi Mort de Rire :-()
12 machines, 25000 visiteurs, site down, moi je vois que ça hein ! Parce que le nano-réseau de TO7, faut pas déconner, c'est moins crédible ;-)
Tiens, dans la catégorie site institutionnel français sous drupal y'a encore mieux ici (Source BlueTouff)
http://www.legrandparis.culture.gouv.fr/?q=admin/
J'arrive pas à comprendre comment ils arrivent à avoir des 'Headers Allready send".. Sauf à écrire des modules qui font des printf...
Ici c'est simple, l'utilisateur a plus les droits d'UPDATE sur une table et donc ca sort un vieux message, je pense qd meme pas qu'il y ait de printf ici ;)
Purée, ce qui veut dire que leur cache est stocké en base de donnée, excellent pour les perfs... Si c'est la même boite qui a fait france.fr, on a l'explication. Et c'est pas en changeant d'hébergeur que cela va améliorer les choses...
Société qui a développé le site : modedemploi, Hébergeur : vert2all, Registar du nom de domaine : integra. Un joli fiasco …
Je vais pas me faire l'avocat du diable, mais le registrar a rien a voir ds cette affaire hein ;)
Oui alors d'accord avec Tostinni, le registrar, je vois pas bien le rapport avec la choucroute.
Pour ce qui est de l'hébergeur, je trouve injuste à ce stade de taper dessus comme il est fait (il y a eu une annonce indiquant qu'ils allaient en changer). C'est peut-être eux la source du problème, je ne sais pas. Mais ce que je sais d'expérience, c'est que lorsque les développements merdent, c'est toujours l'hébergeur qui est désigné comme le coupable. Ça mange pas de pain, et ça permet de défausser d'un paramétrage ou d'un code mal gaulé (genre "c'est des bouses vos machines, vos lignes bouchonnent, c'est tout vot' faute bla bla bla"). Et même si c'est le cas, cela prouve qu'une fois de plus, y'a comme l'oublie d'un vrai chef de projet qui travaille, dés le démarrage du projet, avec l'hébergeur pour anticiper les problème et surtout écouter leurs conseils (les devs sont aussi très fort pour délirer sur leur machine-de-tueur-qu-ils-sont-tout-seul-dessus et couiner sur l'infrastructure lorsque cela se plante).
Perso je leur laisse le bénéfice du doute d'autant plus que j'aime bien les concepts qu'ils mettent en oeuvre.
Merci Yoran pour cette analyse. Ce fiasco met sous les projecteurs Drupal et certains ses détracteurs se retouvent du coup également sous le feu des projo. C'est le cas notamment d'un blogueur français qui semble même le détester..et qui, au travers de son article, dit expliquer objectivement la raison de sa haine..la façon dont c'est écrit me fait un peu penser à l'attaque en règle qu'avait subit Linux de la part de MS. A la différence qu'ici ce ne sont pas 2 produits qui sont comparés mais plutôt 2 approches de la réalisation d'un site web : le modulaire VS le "sur mesure". A la façon de la communauté Linux qui avait répondu point par point aux critiques, ne serait il pas possible que qqun publie une réponse ?
Ce serait sûrement possible si tu nous donnais le lien vers le billet de blog en question :)
voici le lien en question.... : http://www.freeblogware.org/2010/06/pourquoi-je-deteste-drupal-et-la.html
Ah bé ce post là je connaissais, j'avais même laissé un commentaire. Le problème est que sur les fondamentaux techniques, l'argumentaire se tient plutôt bien. On peut apprécier Drupal sans pour autant devenir aveugle sur ses lacunes (orientation objet lacunaire par exemple).
Ca y est, il est en route !
Bonsoir,
je me permet à mon tour de laisser des commentaires :)
@Christophe je souhaitais faire deux petites mises au point : tu précises que je déteste Drupal, ok, ceci est parfaitement assumé. En revanche, je conteste le terme de haine ! La haine serait aveugle et infondée ; en l'espèce, j'ai argumenté ma détestation de ce système qui est donc, je le maintiens, objective. Mais trêve de sémantique :) Je voulais aussi rappeler mon attachement au logiciel libre et à GNU/Linux, car cette comparaison avec MS face à Linux me chagrine un peu. Je suis utilisateur de GNU/LInux depuis... 1994 si je me rappelle bien, ou 1995 au pire. En outre, contrairement à MS vis-à-vis de GNU/Linux, je n'ai rien à gagner à critiquer Drupal. Je le fais par simple conscience professionnelle, rien de plus. Et je peux t'(assurer que de ce point de vue, ça ne m'attire pas toujours les bonnes grâces ni de mon patron, ni de mes clients ;)
@Yoran : je me dois de saluer ton objectivité et ta "sportivité" dans ce débat. Ce que je n'avais pas fait, je viens de m'en rendre compte, après que tu as laissé un commentaire sur mon blog. J'en suis désolé, car je tâche de toujours répondre aux commentaires intéressants. Voilà un oubli au moins partiellement réparé :)
Un utilisateur de GNU/Linux... Je comprend mieux le regard critique pour le coup... Et c'est toujours amusant de voir comment une approche de ce genre, même structurée, se heurte à la pensée techno-religieuse, n'est-ce pas ? De mon côté, je prends avec plaisir ton salut même s'il ne s'agit pas réellement de "sportivité". Déjà parce que techniquement nous sommes grosso-modo d'accord. Il est difficile de nier que Drupal a subit une influence windowsienne et transposant (je caricature :-) le concept de base de registre sur celui de base de données. J'aurais largement préféré une approche linuxienne laissant ceci à de bon vieux fichier aisément déployables. Difficile aussi de nier que l'architecture modulaire souffre de l'absence d'approche objet alors qu'elle y aurait trouvé là une place parfaite. Difficile aussi de ne pas déplorer un développement de plus en plus piloté par l'interface graphique, ce qui entraîne des hérésies comme la création programmatique de vues en passant par de titanesques tableaux imbriqués qui ne sont que l'image des dits interfaces, là où l'on attendrait une "QueryAPI" qu'utiliserais views.
Mais là où je suis moins d'accord c'est lorsqu'il s'agit de noyer ce bébé dans l'eau de son bain. J'ai effleuré pas mal d'autres CMS en PHP (modX, SPIP, WordPress, SilverStrip entre autre), et pour ce que j'ai pu en voir, Drupal est tout de même le plus complet. A titre d'exemple, là où la majorité des autres frameworks se cantonnent à MySQL (que je n'aime pas beaucou), il est l'un des seuls à avoir un aussi bon support pour PostgreSQL (et pas mal d'autres en version 7). Le cœur de Drupal est plutôt bien écrit et si l'on devait se contenter de cela tout irait bien au fond, les ennuis commençant lorsqu'on commence à ajouter des modules. Et là je dirais que Drupal est victime du paradigme "constructeur rapide d'applications WEB" qui viserait autant un publique de développeurs professionnels (comme un framework), que d'amateurs éclairés (comme wordpress). La double cible du paradygme est excellente en soi. Lorsque mon beau frère, non-informaticien et agent immobilier, créé tout seul le site de sa copropriété avec drupal, et ce grâce à Views, je trouve cela génial. Mais un site construit par des professionnels, c'est à dire que l'on fait payer à un client, mérite mieux, sauf si c'est là sa demande express, qu'un assemblage de Views, Panels, et où tout le talent du développeur est dépensé à construire d'abscons hacks pour arriver à contourner leurs logiques limitations.
Tout cela pour dire que si tu prends juste Drupal Core, adjuvé tout au plus d'un CCK et d'une poignée de modules légers, tu disposes d'un CMS fiable, rapide et efficace qui laisse au développeur un grand champ de liberté en le délestant d'une grosse partie de la complexité d'une application WEB moderne. Après je suis du monde Java, et je ne connais pas bien les framework PHP. Mais ce que je peux dire, c'est qu'utilisé ainsi, Drupal est un framework qui tient largement la route face à ce que j'ai pu utiliser de l'univers J2EE. En ce sens, Drupal reste pour moi le meilleur (ou le moins pire selon les angles ;-) des framework CMS en PHP.
Contrairement à ce que tu affirmes, SPIP gère sa base dans MySQL, SQLite ou postgres, et est aussi capable de gérer des bases de données "externes" (et en même temps que la sienne propre) dans n'importe lequel de ces sgbd. Ainsi par exemple je clone ma base de photos flickr dans un fichier .sqlite, et mon SPIP qui tourne sous postgres peut faire des pages intégrant des "boucles" sur ma table sqlite.
Relis bien, je n'ai absolument rien affirmé de tel. Je ne donne qu'un exemple de complétude qui est à prendre parmi d'autres éléments de comparaison. Je suis toujours prudent sur ce genre de points car je n'ai que survolé les autres CMS, et ne peut donc rien affirmer. C'est pour cela que tu ne m'entendras jamais dire que Drupal est le meilleur. Il s'agit juste là d'un état de mes connaissances.
En étant très flou dans ton assertion ("la majorité de...") tu laissais penser que seul Drupal gérait correctement autre chose que MySQL. D'où ma précision. C'est un sport national de dauber sur SPIP -- mais il y a suffisamment de bonnes raisons de le critiquer, il n'est pas nécessaire d'en inventer :-)
Désolé pour la formulation, je vais changer cela pour casser l'équivoque.
Ceci dit, le sport national dont tu parles est pour moi la conséquence d'un trait de fonctionnement plus général, issue j'imagine d'une mauvais digestion des religions du livres, et consistant à penser que l'Outil Unique est capable de répondre à tous les besoins. Et le corolaires de tout ça, sont des guerres de technoreligions sans fin et sans fond sur le thème "Mon outil est mieux que Ton outil, et que si t'es pas d'accord pour en changer, ben je te crame sur un bucher" :) Ce qui est le plus amusant avec cette analyse est que lorsque Drupal décroitra au profit du CMS tartimuche, les tartimucheurs, qui ne seront autres que des drupaleux récemment convertis, tiendront exactement le même discours sur Drupal qu'aujourd'hui avec SPIP (ou Joomla, cf l'article que le petit monde de Drupal trouvent jubilatoire et se retweete à tours de bras : http://www.flbab.com/blog/9-death-of-joomla ).
Au delà du naufrage du france.fr, je me suis livré aussi à un exercice du meme genre en essayant de comparer les capabilités des différents CMS à la tenue en trafic : http://www.spip-blog.net/CMS-et-sites-a-fort-trafic-parlons-chiffres.html
Je retiens le 175 000p/j/serveur que tu donnes en mesure sur une journée sur un des serveur de Mediapart. Par contre, je pense que la conversion minute<->journée ne peut se faire sur une base de 24h compte tenu de la répartition non uniforme du trafic. J'ai plutot l'habitude de prendre 12h comme base.
Oui j'ai lu ton article lorsque je me documentais pour celui-là (j'ai laissé un commentaire il me semble), trés intéressant.
Pour ce qui est du volume de page, je retiens ton principe de 12h, mais je pense que je vais surtout ajouter un accumulateur à mon module de stats de sorte à me donner les chiffres à la journée qui est une donnée qui me manque pour améliorer l'optimisation.
Maintenant pour ce qui est du volume à mediapart, ne pas oublier que les chiffres que je donnes sont trés loin des limites de la machine, là on est plutôt sur les limites actuelles de la fréquentation du site. Et pas facile de faire des tests de charge à ce volume. Mais je suis persuadé qu'on a mangé deux fois plus pendant l'affaire Bettencourt, et là on était vraiment au taquet (un peu plus que le taquet en mâtinée avant grosse optim d'ailleurs).
"moins vite ne signifie pas obligatoirement beaucoup plus lent" : cqfd !
pour le reste au lieu de comparer la longueur de leur nouille les devs de nos outils préférés feraient mieux de se piker mutuellement les bonnes idées et le bon code. Tout le monde en bénéficierait.
Je ne suis pas sur que je l'aurais exprimé aussi élégament, mais sur le fond, je suis bien d'accord. Et dit encore d'une autre manière, je suis persuadé qu'en y mettant du mien, je pourrais faire avec SPIP un bouzin aussi terrible que le pire des drupaux. Si, si, avec en se lâchant, en ignorant complètement la manière dont il fonctionne, avec un langage comme PHP de mon côté, je pense que je peux y arriver ;-)
On commence quand ?
Pour ceux qui aiment bien lire des tutos sur les perfs de Drupal, je recommande vivement la lecture de http://2bits.com
D'ailleurs, il parle d'un serveur qui tient 2.8M pages vues par jour...
http://2bits.com/articles/presentation-28-million-page-views-day-70-mill...
Article original: http://2bits.com/articles/can-a-drupal-web-site-handle-a-million-page-vi...
Oui leur démo est assez intéressante mais entre nous, le module à retenir dans cette histoire est clairement boost. Ce truc fonctionne du feu de dieu même s'il faut un certain temps pour comprendre et correctement utiliser toutes les options. Personnellement, pour la majorité des sites anonymes, je conseille boost+css_emimage (assez génial ce module) et mod_deflate sur le serveur apache.
Après il n'y a pas de secrets, on retombe toujours sur la même problématique du ration authentifiés/anonymes. Boost permet de régler définitivement l'aspect anonyme mais pour ce qui est de l'authentifié c'est une autre histoire. La grosse complexité de Drupal en terme de performance n'est pas de régler son compte au trafic anonyme, mais au trafic authentifié. Et là cela devient tout un art et chaque site est un cas particulier.
Je découvre cet article et tous les commentaires qui suivent avec grand plaisir, rien de tel qu'un petit coup de gueule pour lancer un débat :D Merci Yoran ! Et je dois dire qu'on apprend énormément de choses à travers les visions et expériences de chacun, souvent plus que dans un livre ou un site dédié à Drupal par exemple...
Concernant le "petit" souci France.fr, je me demande qui est censé prendre des coups dans l'histoire, plutôt la SSII qui conçoit le site ou la société d'hébergement, ou les deux ? Personnellement je pense que le lead développeur (ou CP tech, ou je ne sais quel autre nom on peut encore lui donner) de la première doit proposer une architecture adaptée au projet, en incluant les éventuels Varnish/APC/Memcached/Nginx etc, et donner des conseils de configuration des serveurs (apache, php, mysql,...), mais en ce qui concerne la configuration des différents outils cités précédemment il faut savoir que les développeurs ne sont pas forcément formés sur ces technologies (malheureusement !). Alors oui il est possible de donner des préconisations en se basant sur son expérience pro/perso ou en suivant divers conseils trouvés sur des sites et autres blogs plus ou moins professionnels (douteux ?), mais c'est d'abord à l'hébergeur de connaître les possibilités d'optimisation du matériel mis à disposition, et les différentes configurations possibles et optimales selon les cas.
Admettons qu'on ne prenne pas en compte le code (c'est-à-dire des problèmes propres à la conception du site) : si le client s'aperçoit que rien ne change en terme de performances après avoir mis en place un Varnish ou autre système de cache côté serveur (donc côté hébergeur), ce n'est pas la société qui conçoit le site qui est en faute mais bien l'hébergeur, non ? Je veux dire, l'hébergeur a pour rôle de veiller à la disponibilité constante d'un service (ou haute disponibilité : http://fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9) , il doit donc savoir comment réagir à une défaillance de cette disponibilité de son côté, et paramétrer l'architecture. Bien entendu pour cela, il doit demander à la société qui livre le site de lui fournir toutes les informations relatives au fonctionnement de ce site, que ce soit les webservices appelés ou le type de framework/CMS utilisé, afin de proposer une architecture adaptée.
Par là je veux dire que des deux côtés, SSII comme hébergeur, des efforts doivent être fournis pour réfléchir et décider ensemble d'une solution optimale. Le premier plus dans la proposition d'architecture, le second dans sa configuration, et son optimisation.
On gagnerait sans doute à apprendre davantage de l'autre, à travers des interventions croisées peut être ? Des formations pratiques de configuration d'architecture web ? Et dans le même temps, côté hébergeur, des formations sur tel framework ou tel CMS ? Ce n'est pas pour rien qu'on voit de plus en plus de société d'hébergement "spécialisée dans l'hébergement de CMS", notamment Drupal.
Publier un nouveau commentaire