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).
