Hooper.fr, un an de bugs - Journal de bord d'un webmaster amateur

Je ne connaissais alors pas encore le gout savoureux du fouet...

Des sites web, j'en ai déjà réalisé une petite quinzaine au cours de mon humble carrière de "webmaster amateur" (je ne me considère pas professionnel dans le sens où je ne me suis jamais vraiment consacré à cette activité à plein temps, disons que "faire des sites" fait partie de mon arsenal de travailleur indépendant et que ça m'a servit occasionnellement à renflouer mon porte monnaie), institutionnels, associations, gites ruraux, 1 boutique en ligne, 1 architecte... bref, à boire et à manger ;p

Pour ce faire, depuis quelques années déjà j'utilise drupal, un outil de gestion de contenu en php+mysql très populaire, réputé pour sa robustesse et sa modularité (presque 7000 modules disponibles pour la version que j'utilise! c'est vous dire la modularité ;p)

Jusqu'ici cette modularité m'aura toujours permis d'ajouter les fonctionnalités désirées par les clients sans avoir à faire de réél effort de programmation (ce qui est le but de ce genre d'outils)

Ça n'allait pas durer...

Un forum classique, ça peut ne pas être compliqué, si on décide d'utiliser juste une plateforme de forum déjà existante et populaire comme PhpBB. (et encore, après coup je me demande comment ça aurait résisté à ce trafic)

Mais si cette solution avait l'avantage de proposer un système complet et fonctionnel, elle créait un certain nombre de problèmes:

• L'ajout d'une plateforme supplémentaire à gérer en plus de drupal: code différent, utilisation différente, base de données différente, bugs différents...

• La difficulté d'intégration à l'intérieur du site: et là je ne parle pas seulement de l'apparence (qui n'est pas vraiment un soucis) mais aussi par exemple de l'intégration des données utilisateurs, l'activité des membres sur le forum doit être liée à leur activité sur le reste du site, en gros il aurait fallut faire en sorte que les utilisateurs du forum soient liés aux utilisateurs du site. mmm... pas optimal tout ça.

Partant sur l'idée d'optimiser au maximum les ressources nécessaires au fonctionnement du site (et du développeur ;p), et sachant que drupal proposait déjà un série de modules dédiés à la construction de forums, je m'orientais donc vers une solution "tout drupal".

Les semaines passent, puis les mois, le site n'est encore qu'au stade de projet, jusqu'à la fin du printemps où à la suite d'une nouvelle entrevue nous enclenchons la marche avant en vue d'un lancement pour la rentrée.
L'été arrive et je commence tranquillement à créer et mettre en place la structure du site, n'hésitant pas à prendre du temps pour comparer certains modules proposant le même genre de fonctionnalités pour être sur d'utiliser les plus adaptés et les plus performants.

L'implémentation du forum s'avère comme prévue un peu compliquée: il manque quelques fonctionnalités qu'on retrouve habituellement dans les forums modernes, il va falloir trouver d'autres modules, il va falloir sans doute modifier le code du module de forum, il va falloir galérer un peu pour gérer correctement les droits d'accès...

Ok, bon, rien n'est fini, il manque encore plein de trucs, tout n'a pas été complètement testé, j'ai pas passé suffisamment de temps sur l'habillage, j'ai déjà repéré quelques petits bugs fâcheux, lancement dans 3, 2, 1, et... OK, bon, ça roule, ils sont 50 connectés sur le site, ok 100, ok 150, ok bon... 200, 300, c'est pas mal... 301... What The... FATAL ERROR!, 400... FATAL ERROR!, 500... FATAL ERROR! 600... FATAL ERROR! 700... FATAL ERROR!!!

Plus de 2000 inscriptions en moins de 24h, et jusqu'à 700 connexions simultanées !

En moins de 24h ce site avait généré plus de trafic que la totalité du trafic généré par tous mes précédents sites réunis en ligne depuis toutes ces années ! Bon, j'exagère peut-être un peu mais je dois pas être si loin de la vérité, mes précédents sites ayant un public beaucoup plus local et présentant pour la majorité un aspect beaucoup moins communautaire (sans gestion d'utilisateurs poussée, et suuuuuurtout sans forum)

Il s'avéra donc que la communauté du hooper fut bien plus importante que prévue...

Bon ok, le site n'est pas optimisé et le trafic est trop important pour que le pauvre serveur mutualisé d'OVH tienne le coup.
Il faut que je me fasse une raison: ce n'est pas un simple site auquel on a affaire, c'est un BON GROS SITE.
Une seule solution pour régler le problème au plus vite: faire une migration complète vers un serveur dédié dans les plus brefs délais.

Ça y est je le sais: on y est. Je respire un grand coup, j'ouvre la porte, puis je commence à descendre les marches, lentement, ça sent l'humidité et le cassoulet, c'est sombre, ça y est, j'y suis, je m’apprête à pénétrer dans la cave...

En général lorsqu'on veut publier un site "normal" (=petit trafic) sur la toile, on fait souvent appel à des solutions de type "hébergements mutualisés".

D'abord parce que ce sont les solutions "pro" les moins chères, ensuite parce que tous les services "usuels" sont pré-configurés et prêts à l'emploi, vous n'avez plus qu'à mettre vos fichiers et votre code php sur votre espace disque, puis à créer et gérer votre base de données via une interface web fournie et c'est dans la boite.

Et enfin parce que ce genre de solution est en général largement suffisant en terme de performances pour publier un site "normal".

Le plus gros avantage étant bien sur que le créateur du site n'a pas besoin de gérer la partie serveur, tout ce qui est sécurité et gestion des services et du trafic est pris en charge par l'hébergeur. Il peut alors se concentrer uniquement sur les bugs que provoquent son code ;p

Mais il y a bien sur un revers à cette médaille...

D'abord l'aspect "mutualisé" de l'hébergement: en gros ça veut dire que plusieurs sites sont hébergés sur le même serveur, ça veut dire que le trafic et les performances du serveur sont partagées ("mutualisées") entre les différents sites, donc moins de performances (ce qui n'aura pas vraiment d'impact sur un site "normal")

Ensuite les limitations au niveau des services: tout est pré-configuré pour gérer les différents sites hébergés sur le serveur, et donc pour des raisons de sécurité la configuration du serveur et de tous ses services n'est pas accessible aux clients.

De plus, pas moyen d'installer de programmes supplémentaires sur le serveur, il faut se contenter de ce qui est fournit, et des limitations qui ont été appliquées soit pour des raisons de sécurité, soit en fonction du prix que vous avez payé (qui peut définir la taille de votre base de données par exemple)

On a besoin de plus de performances, on a besoin de pouvoir configurer et customiser tous les services, on a besoin d'ajouter des services, on a besoin d'une base de données sans limitation de taille, bref: on a besoin d'un serveur dédié, d'un ordinateur tout entier rien qu'à nous, et où on puisse faire tout ce qu'on veut dessus...

Jusqu'à présent je n'étais pas vraiment le webmaster du site, au sens strict du terme.

Le webdesigner, c'est celui qui s'occupe de la structure et de l'apparence du site.
Le développeur web, c'est celui qui s'occupe de la programmation du site.
Le webmaster, c'est celui qui s'occupe du serveur sur lequel est hébergé le site.

Je suis essentiellement webdesigner au départ, un petit peu développeur mais la partie programmation m'est habituellement grandement épargnée par l'utilisation de drupal et de ses multiples modules, j'ai ceci-dit quelques notions de php et de javascript qui me permettent de pouvoir parfois modifier quelques bouts de code en cas de nécessité. (Ooooh que oui j'allais devoir en modifier du code ;p)

Il fallait maintenant que j'endosse une nouvelle casquette: weeeeebmasteeeeeer!!!

Descriptif de la mission:
Installer, configurer, sécuriser, optimiser, maintenir:

• Un serveur de nom de domaine (DNS) (bind)
• Un serveur HTTP (apache+php)
• Un serveur de base de données (mysql)
• Un serveur de cache (memcache)
• Un serveur de mail (postfix)
• Un firewall (iptables)
• Et une installation de drupal par dessus tout ça (~150 modules)

Miam miam! Voilà qui est appétissant! Tout ça, rien que pour moi? Oh non fallait pas... Si? Bon d'accord.

Amis nerds, amis geeks, attardons-nous un instant sur le choix du système d'exploitation du serveur.
Mon objectif était le suivant: installer uniquement ce qui est nécéssaire à faire tourner le site, rien de plus, rien de moins.

Donc exit les serveurs dédiés pré-configurés, à ce niveau là la seule différence c'est que le système et les programmes sont pré-installés et pré-configurés (dont les programmes inutiles au site qui nous intéresse), et que les diverses configurations sont accessibles via une interface web.

Par chance j'ai déjà eu l'occasion de m'amuser avec toutes ces joyeusetés sur un serveur dédié pour un site drupal l'année précédente, qui avait été créé à partir d'une installation minimale d'ubuntu puis entièrement configurée à la main... ET J'AI PRIS DES NOTES! ;p (Évidemment ce dernier ne générait pas l'ombre de l'ongle du trafic de hooper.fr...ça fera une différence par la suite ;p)

Ces précieuses notes vont m'éviter des semaines et des semaines de prises de tête, grâce à elles la migration devrait pouvoir être effectuée d'ici quelques jours.

L'expérience fut plutôt satisfaisante avec ubuntu, et j'ai beaucoup appris sur le fonctionnement d'un serveur, et de tous ces programmes qui servent à propulser un site web. Mais l'objectif était le suivant: installer uniquement ce qui est nécessaire à faire tourner le site, rien de plus, rien de moins. Je voulais quelque chose d'un peu plus "pur", quelque chose d'un peu plus "proche du code source", je voulais encore plus de contrôle sur le système, je voulais archlinux...

"- Archlinux?! Mais t'es fouuu! Y a des mises à jour toutes les demi-heures, c'est le bordel, c'est pas stable! Pour un serveur en plus, vous n'y pensez pas?!! Et la sécurité?!!!"

Bon évidemment ce genre de commentaire de provient pas de quelqu'un qui a pris le temps de prendre du temps avec archlinux... ;p

Voici mon point de vue:

• "Archlinux vise en premier lieu, et avant toute chose, la simplicité" C'est beau ;p
• Le système de paquets est une merveille, il permet aux programmes installés d'être au plus proche de leur code source original compilé, et il ne touche pas à configuration de vos paquets!
• C'est une distribution en rolling release: les paquets sont constamment mis à jour au fil du développement de chaque programme installé, vous pouvez constamment tourner avec la dernière version du programme en date. Ce qui ne me pose aucun problème, au contraire, les programmes installés sur le serveur sont peu nombreux (par rapport par exemple à une installation de type desktop qui exige un serveur et un environnement graphique ainsi qu'une multitude d'applications), ils sont matures et utilisés dans leur version stable. Si mise à jour il y a, ce sera essentiellement pour corriger des bugs, des problèmes de sécurité et parfois pour ajouter des fonctionnalités ou améliorer les performances. Est-ce que je veux ces mises à jour? Oui! Est-ce que je peux les faire quand je veux comme je veux? Oui! Est-ce qu'elles sont testées avant d'être disponibles? Oui! Bien sur j'utilise le dépôt "stable" uniquement, le dépot "testing" servant à détecter les éventuels problèmes de mise à jour.

Bref, dans mon humble expérience Archlinux est sans aucun doute le système le plus stable que j'ai jamais utilisé (que ceux qui n'ont jamais pété leur ubuntu suite à une mise à jour lèvent la main... j'attends ;p), et c'est en grande partie grâce à sa simplicité qui fait en sorte que vous avez le "total control" sur votre système.

Et pis ça m'plait bien et pis j'fais c'que j'veux alors archlinux à fond les ballons!!! ;p

Ok...

• Sauvegarde de la base de données: Check!
• Sauvegarde des fichiers: Check!
• Copie des fichiers sur le nouveau serveur: Check!
• Importation de la base de données sur le nouveau serveur: Check!
• Vérification que tout fonctionne: ... attends... 2 secondes... 2 secondes... Check!
• Redirection du nom de domaine: bon ça prends du temps c'est normal... Check!
• Ok on reboot!

Ça y est, c'est fait! Et ça à l'air de marcher! En tout cas pour l'instant! Et j'ai pas perdu les données! Je vote oui pour un youpi provisoire!

Le site à l'air de tenir les 700 connexions simultanées sans trop ramer, je vais pouvoir souffler, un peu. Il faudra quand même ajuster la configuration les jours suivants, ajustements parfois un peu rugueux au niveau des "site indisponible" engendrés.

Ok, j'essaie de corriger un maximum de bugs sur le forum (oui je sais il en reste encore), et de rajouter quelques boutons au passage (ils sont pas très jolis mais ils fonctionnent).

Maintenant que le site est online, les modifications sur le forum peuvent s'avérer extrêmement délicates, il faut maintenant prendre en compte le contenu existant, si je modifie la structure des topics il faut que je modifie la structure de tous les topics déjà existants... glups...

Des sections ont été ajoutées dans le forum croulant sous les topics, certaines s'avérant judicieuses, d'autres moins.
Des discussions ont lieu sur la structure idéale du forum, des pistes sont jetées, des tests sont effectués pour créer un système de tri différent (avec des tags), mais rien n'est validé de manière définitive...

Il y aura d'autres problèmes plus importants à régler avant...

Le trafic augmente, la base de données enfle, le serveur commence à montrer parfois quelques signes de faiblesses... Mmm cette odeur... Je la connais...

Ok, va falloir songer sérieusement à optimiser bonhomme, tu te croyais à la maternelle ou quoi? Non, ici t'es chez les grands, alors va boire une menthe à l'eau, profites-en pour t'éduquer un peu, et puis tu reviens quand tu te seras brossé les dents.

Les semaines qui allaient suivre allaient être longues...

Je suis allé m'éduquer auprès de mon ami google, qui m'a bien confirmé qu'on avait affaire là à un vrai site à haut trafic, et que donc chaque détail allait compter...

Me voilà parti pour un truculent voyage: manuels de configuration, tutoriels, forums, blogs, croisement d'informations, sur chaque détail de configuration de chacun des services qui propulsent le site: apache et ses modules, php et ses modules, mysql, les différents systèmes de cache, la configuration de la carte réseau, et bien sur drupal et sa tripotée de modules.

Un monde merveilleux, et vaste. Très vaste. Et les tests allaient prendre des plombes...
Oh oui, les semaines qui allaient suivre allaient être longues...

Je l'avoue maintenant, il m'arrive parfois de m'échapper de la cave par un endroit que je garderai secret qui me permet de régulièrement rejoindre ce que certains appellent: "la vie réelle".

Non, je ne bosse pas sur le site du hooper tous le soirs depuis un an. (oooooohhhh)
J'ai du boulot à côté, j'ai une famille à côté, et il m'arrive parfois même d'avoir quelques loisirs à côté (ooooooooh)

Du boulot: Je m'occupe d'autres sites web, je créé des tracts et des affiches (essentiellement pour des troupes de théâtre), parfois des captations vidéos... bref, selon ce qui se présente à moi.

De la famille: Je suis l'heureux papa d'une petite fille qui avait 6 mois et demi lors du lancement du site. (ça résume suffisamment bien la situation je pense ;p)

Tout ça créé forcément des perturbations quand aux nombres d'heures que je peux consacrer au site, un ptit bébé ça prends du temps, le boulot à côté qui se retrouve à la bourre ça prends du temps...

En décembre par exemple je jouais dans une pièce de café-théâtre (webmaster/comédien? et pourquoi pas? ;p Bon j'avoue c'était un peu exceptionnel, ça fait maintenant quelques années que je ne fais plus le comédien, c'était l'occasion de retrouver mes 20 ans ;p), entre les répétitions et les représentations ça m'a bouffé pas mal de temps au détriment du site.

Au fil de cette année passée il m'est arrivé de bosser sur le site tous les soirs pendant plusieurs semaines, mais il m'est aussi arrivé de ne quasiment rien toucher pendant plusieurs semaines, et puis il m'est aussi arrivé d'y bosser quelques soirs par ci par là pendant plusieurs semaines, l'un dans l'autre j'y ai quand même passé une bonne partie de mon temps libre.

Mais un temps malheureusement pas suffisant pour faire évoluer le site aussi vite que le hooper l'aurait voulu, notamment au niveau de l'apparence et des nouvelles fonctionnalités/ nouvelles sections qu'il aurait aimé ajouter.

Cette "lenteur" de l'évolution du site est essentiellement due à ma noobitude en terme de webmastering de haut niveau, et au fait que j'ai consacré la majeure partie de mon temps à bosser sur le site au niveau du métal, au niveau des performances et des bugs, préférant privilégier la voie du "il faut faire en sorte que le site puisse être accessible à tous ces gens, sans ramer, et ce malgré l'augmentation du trafic et l'augmentation de la taille de la base données" à celle du "faut que le design du site il déglingue, que ça bouge de partout, et qu'on rajoute une nouvelle section tous les mois"

Croyez-moi, la vérité c'est que j'aurais vraiment préféré plonger dans la seconde voie plutôt que la première, pauvre webmaster que je suis devenu...

La combinaison de tous ces critères rendent vraiment compliquée la possibilité qu'une personne puisse travailler avec moi sur le site, c'est que c'est pas facile à trouver! ;p En plus il faudrait que je m'entende avec cette personne, qu'elle prenne le temps de comprendre le code et les configurations en place, qu'on s'accorde ensemble sur les modifications à apporter, tout ça prennant bien évidemment du temps...

Quelques personnes dans la communauté du Hooper m'ont déjà proposé leur aide, et je les en remercie, mais pour l'instant aucune personne ayant de l’expérience avec drupal, experience nécessaire pour pouvoir résoudre les problèmes sur le site.

Ça veut pas dire que je fais pas appel à de l'aide extérieure, mais pour l'instant j'ai plus de chance de trouver des réponses à mes problèmes sur les forums et les bug trackers de drupal et autres sites de webmastering que sur les forums du hooper ;p

Mais si quelqu'un ici a de l'experience avec drupal et qu'il souhaite donner un coup de main, qu'il n'hésite pas à se manifester. Dans le futur j'essaierai aussi d'exprimer un peu plus en détails sur le forum certains problèmes auxquels je suis confronté, au cas où quelqu'un connaisse une solution.

En attendant Google reste mon fidèle allié ;p

1er janvier, il neige sur le site! (oooooohhh)

Je joue encore au théâtre jusqu'à la mi-janvier, essayant de poursuivre ma quête douloureuse pour un serveur performant en parallèle.

...hum... effectivement, ça urgeait. Jusqu'à présent c'est moi qui m'occupait de ça quand j'avais le temps, mais la communauté avait bien grandi, et il fallait maintenant être plus réactif. Il fallait que je donne un peu d'amour aux modos, les pauvres, je ne leur ai pas donné assez d'amour, ce qui n'a pas rendu facile leur tâche déjà ingrate...

Pendant ce temps, les nuages commençaient à se regrouper et noircir autour du serveur...

Les Fatal Errors sont de retours!!! Oh joie! Félicité! Allégresse!!!

Le trafic a encore augmenté (on a déjà vu plus de 1200 personnes online), mais surtout, ooooh surtout, la base de données est devenue énoooorme! La communauté sur le site est hyper active, ça n'arrête pas de poster, c'est complètement dingue. Ce qui à ce moment là est une bonne nouvelle pour le site, une mauvaise nouvelle pour le site, et une trèèèès mauvaise nouvelle pour le webmaster.

Le site du hooper victime de son succès? Victime de son noob de webmaster? Peut-être un peu des deux...

Bon... ok, le problème se situe au niveau de mysql, bon ok, y a trop de requêtes, ok, y a encore pas mal de mémoire vive disponible sur le serveur, super, donc il suffirait d'augmenter le nombre de connexions disponibles en utilisant un max de RAM, y a une bonne marge, ça risque de faire l'affaire, alors, donc il suffit que... que... hein?! ...quoi?! … vous êtes surs?... surs de surs? ... noooOOOOONNNNNN!!!!!

Erreur fatale. Erreur de noob. Mysql est limité à 3Go d'utilisation de RAM pour ses processus sur un système 32bits. Des gigas, j'en ai 12 en tout sur la machine, et les autres services sur le serveur n'en prennent qu'une poignée. Et j'ai installé un système 32bits sur le serveur. Et j'ai besoin d'utiliser au maximum les performances de la machine. La con de moi.

Votre mission, si vous l'acceptez: tout réinstaller en 64bits, sans perdre de données

• Récupérer tous les fichiers de configurations
• Récupérer tous les fichiers du site
• Récupérer la base de données
• Vérifier le mécanisme de migration du site
• Vérifier le mécanisme de migration du site
• Vérifier le mécanisme de migration du site
• Vérifier toutes les notes sur la configuration du serveur
• Respirer un grand coup
• Reformater le disque dur du serveur
• Réinstaller le système en 64bits
• Réinstaller et reconfigurer tous les services nécessaires
• Réimporter les fichiers du site
• Réimporter la base de données
• Vérifier que tout fonctionne
• Un reboot pour la forme
• Vérifier que tout fonctionne
• Voilà

Alors, t'acceptes ou bien?
- … Euuuh... Kowabungaaaaaa!!!

Les semaines qui allaient suivre allaient être longues...

La petite va fêter ses 1 an, les vacances de février s'annoncent, ça va m'éloigner de la cave pendant un moment...

Correction de quelques bugs, lecture trimestrielle de mes messages privés, ré-agencement de l'en-tête pour y accueillir le nouveau bloc d'annonces demandé par le hooper et le nouveau bloc lakitu. Les vidéos indices ont fait leur apparition les semaines précédentes.

L'opération Kowabunga et ses suites ont permis de résoudre enfin la plupart des problèmes liés à la configuration du serveur, les Fatal Errors ont disparus, le trafic est fluide, tous ces efforts commencent à être payants, je commence à mieux comprendre le fonctionnement de mysql en interne. J'ai installé plusieurs systèmes de monitoring et de profilage qui me permettent d'avoir un aperçu plus détaillé de l'activité sur le système et des endroits spécifiques où ça coince.

Et des endroits spécifiques où ça coince, j'allais en trouver...

Ok, le serveur semble relativement bien configuré, apache et mysql semblent stables et solides avec le trafic actuel. C'est bien. C'est suffisant? Non c'est pas suffisant.

Le trafic peut encore augmenter, mais surtout la base de données va très certainement augmenter, et les temps de requêtes vont potentiellement devenir plus importants.

Il faut optimiser les temps de requêtes effectués sur le site, drupal est très intensif au niveau de l'utilisation de la base de données, et le monitoring me permet de remarquer certaines requêtes plus longues que d'autres qui reviennent régulièrement, et qui peuvent potentiellement avoir un impact sur les performances en cas d'augmentation de l'activité sur le site.

Le challenge étant d'arriver à trouver quelle est la partie du code qui pose problème, du quel des 150 modules installés, et comment résoudre le dit problème.

Bref, optimiser drupal, trouver les points de lenteur, réduire les requêtes, optimiser les caches, patcher le code pour une performance optimale...

La bonne nouvelle c'est que j'allais enfin pouvoir retirer ma casquette de webmaster, la mauvaise nouvelle c'est que j'allais devoir mettre celle de webdéveloppeur...

Ah c'est sur que si ça pouvait régler tous nos problèmes comme par magie ce serait tip top!
Sauf que rien n'est moins sur! Ca ne règlerait pas vraiment grand chose en cas de:
- problème de configuration au niveau d'un des services.
- problème de performance au niveau de l'application web.

En général et grosso modo, quand on prend un 2ème serveur, c'est pour séparer le serveur de base de données du serveur http, de façon à avoir mysql sur une machine, et apache sur l'autre, pour que chacun ait ainsi accès au maximum de ressources. Et si vraiment l'utilisation de la base de données est intensive, on ajoute un 3ème serveur dédié lui aussi à mysql, de façon à avoir 2 serveurs mysql synchronisés entre eux et se partageant le trafic, puis on rajoute un 4ème serveur pour avoir 2 serveurs apache synchronisés entre eux et se partageant le trafic... etc... en un mot: overkiiiiiill!

Avec le trafic actuel ces 2 services n'ont en théorie pas besoin de tant de puissance pour l'instant, depuis le passage au 64bits et l'optimisation de l'utilisation de la mémoire et du reste, le nombre de requêtes et de connexions sur le site arrivent facilement à être prises en charge, séparer les serveurs aurait un petit impact, mais pas encore du tout suffisant pour justifier une telle opération, qui comme vous vous en doutez est loiiiin d'être triviale.

Ce n'est donc pas du tout une question d'économie d'argent (ça fait déjà un moment que hooper m'a donné le feu vert pour ça, il serait prêt à prendre une brouette de serveurs s'il le fallait ;p), mais tant que le site n'aura pas été entièrement optimisé et vérifié au niveau d'eventuels bugs de performance on n'aura pas une réelle idée des capacités du serveur actuel....(et en l'occurence des bugs de performances on en a encore)

Bon. Ben y a plus qu'à finir d'optimiser le site...

Le monitoring a commencé à rapporter quelques fruits, j'ai pu repéré 2 modules qui ralentissaient le site, un lié à la traduction dont j'ai pu me débarrasser facilement, en me débarrassant aux passage des bugs de traduction qu'il générait, mais le second posait quelques problèmes, puisqu'il s'agissait du module de recherche.
Mmm... fâcheux... Je l'ai désactivé provisoirement pour voir la différence sur les performances... Mmm... Il va falloir que je trouve une autre solution pour indexer le contenu du forum... Mmm...

Bon, pendant ce temps j'en profite pour ajouter des fonctions d'admin supplémentaires au hooper et aux modos, le plus je leur donne du pouvoir, le plus je gagne du temps pour pouvoir m'occuper du reste.

Ok... On va commencer par les sondages...

La résolution d'un bug a quelque chose de fascinant: un bug, on peut s'y attendre, il peut nous prendre par surprise, parfois il vous saute à la gueule, parfois il faut passer des heures, des jours, des semaines à le traquer pour pouvoir le dénicher, on peut le résoudre en 5 minutes, 1 heure, plusieurs jours, des semaines, des mois, on peut ne jamais réussir à le résoudre, il peut nous faire transpirer, il peut nous faire rire (souvent jaune), il peut nous détruire le moral, il peut nous rendre fou, il peut nous faire mal, trèèès mal, et faire ressurgir en nous à la fois un certain masochisme mais aussi un certain un esprit conquérant... La résolution d'un bug procure souvent beaucoup de satisfaction, surtout si la bataille a été rude...

Fascinant n'est-ce pas? ;p ... et extrêmement CHRONOPHAGE!!!

Bon, les sondages, ok. Je sais qu'il existe une poignée de modules de sondages pour drupal plutôt populaires, je vais passer quelques jours à les tester un par un sur mon ordi... Ok.. Bon, c'est toujours la même chose, l'idéal ça serait de pouvoir avoir les fonctionnalités de celui-ci, mais sans ça, et en combinant avec les fonctionnalités de celui-là, sachant bien sur qu'on ne peut pas utilser les 2 en même temps... Ok... Bon ben on va prendre celui-là, c'est le seul qui nous permettra d'intégrer facilement un sondage dans un topic déjà existant...

Bon, ça fonctionne à peu près, il va falloir adapter 2 ou 3 trucs, ok, maintenant voyons comment ça réagit si je l'intègre dans le site à l'intérieur du forum... Mmm... Mmm... Et pourquoi donc? ...Mmmgrmlllmmm... Bon, je sens que ça va être long...

J'ai rien fait!!! C'est pas moi j'vous jure!!! Qu'est-ce qui se passe??! Qu'est-ce que j'ai fait??! J'ai touché un truc ou quoi? ... Bon, j'en ai bien touché des trucs (par rapport aux sondages), mais rien qui aurait pu foutre ce bordel!!! C'est pas possible c't'histoire!!! Qu'est ce qui se passe??!!!

Pendant presque 4 jours le serveur va partir en couille et "freezer" de manière aléatoire... et pour une fois c'est pas ma faute!

Gros coup de chaud... puis on se remet au boulot!

On est déjà mi-avril, hooper peut enfin faire un test en live des sondages dans le forum, ça m'aura pris plus de temps que j’espérais...
Tout se déroule comme prévu, il a pu mettre mettre en place son sondage à l'intérieur de son topic, les membres peuvent alors voter, annuler leur vote, et les résultats s'affichent au fur et à mesure, tout est ok. Super.

Le sondage se termine, hooper bloque le topic, eeet le sondage disparaiiiit... super... Aaarglll... Ce module de sondage va me rendre fou... Non il ne devrait pas disparaitre, il devrait rester là et montrer fièrement les résultats, arglll...

J'ai un problème avec la gestion des droits d'accès à l'intérieur du forum, je le sens, le système est beaucoup trop restrictif sur certaines opérations, ça m'a déjà donné du soucis lors de la création de certains outils pour les modos. Les résultats du sondages ne sont pas perdus, je les vois dans la base de données, mais la configuration du sondage a été effacée... Grrrmlll..

En plus, j'ai ajouté la possibilité de pouvoir donner le droit de créér des sondages à certains membres uniquement, et il s'avère que les options de sondage apparaissent bien quand ils créent des nouveaux topics, mais n'apparaissent pas sur leurs anciens topics... Grrrmmllmm...

Y a un truc qui couille... quelque part...

... les semaines qui allaient suivre allaient être longues...

Le problème avec mai, c'est que c'est un mois rempli de jours fériés et de ponts en tous genres... Il va falloir s'occuper un ptit peu plus de la ptite famille! ;p

Je m'occupe d'abord des pages spéciales de donation pour le serveur minecraft de mercenaire76, qu'il me demandait déjà depuis un bon moment. (oui, au cas où si vous m'envoyez des messages privés, sachez que je peux être parfois trèèès long à la détente, certains ont déjà pu s'en rendre compte ;p)

Bon, maintenant je me concentre uniquement sur cette histoire de chat et rien d'autre, mmm... miam miam... je sens que ça va être bien chaud...

Non mais un chat... genre un chat? genre communication en temps réel? A l'intérieur du site? Et je lui ai dit que c'était possible? Sérieux? Bon. Ok, même si les optimisations sur le site ne sont pas finies le serveur est stable, le trafic est stable, disons que si y a 50 personnes sur le chat ça devrait pouvoir le faire... bon... ils seront jamais 50, ils seront plusieurs centaines... c'est sur... c'est des dingues... Ok... Bon, alors voyons ça...

Une poignée de modules de chat sont disponibles pour drupal, un seul est spécialement prévu pour être un peu performant (j'y reviendrai), le choix est vite fait: ce sera celui-là. On va voir s'il tient la route et comment il tient le choc...

Bon, il m'aura fallut quelques semaines (moi de mai oblige) pour tester et modifier le code du module de façon à ce que tout s'intègre bien dans le site et fonctionne comme voulu, tout en essayant d'optimiser le site où je pouvais. Les avatars des membres s'affichent dans la fenêtre de chat, ils peuvent formater leur messages en bbcode, j'ai pas mal d'options derrière pour ajuster les performances, le test en privé avec hooper et les modos est plutôt encourageant (restent encore quelques petits bugs qui seront résolus relativement rapidement), bon. C'est l'heure du crash test avant l'E3...

... Comment dire... Imaginez que vous faites tranquillement la sieste allongé(e) sur la plage, bercé(e) par les clapotis des vagues, et que vous êtes subitement réveillé(e) par un ouragan force 12 qui vous arrive en pleine gueule... et que cet ouragan dure 3 jours d'affilé sans que vous puissiez quitter la plage... et vous êtes en slip...

... Bon, va falloir serrer les dents ... pendant 3 jours...

Le crash test a révélé quelques petis soucis d'affichage et d'ergonomie, qui ont pu être résolus, mais surtout, oohhh surtooooouuuut, il a révélé qu'au delà de 100 membres connectés sur le chat, le site commençait à partir doucement en cacahuète...

Un bon gros site qui rame sa mèèèèère... pendant 3 jours... épiques...

Bon, y a un problème avec apache, y a trop de requêtes http, ça surcharge le serveur. Je peux optimiser ça en augmentant le nombre de connexions possibles pour apache et en ajustant les paramètres de mises à jour du chat. Allez, on essaie de modifier ça au plus vite... Arglll... Il faut que je ferme le chat à chaque fois que je veux faire des modifs... C'est sur ils vont s'en rendre compte...

Mais y a surtout un grooos problème avec mysql: certaines requêtes usuelles provenant des membres naviguant sur le forum et qui mettaient d'habitude moins d'1 seconde à s'executer, se mettent tout d'un coup à ramer, puis rapidement à se bloquer indéfiniment, bouffant les connexions disponibles au fil des secondes, pour finir par rendre la base, et donc le site, indisponible. Je redémarre alors le serveur mysql, coupant toutes les connexions et rendant le site indisponible pendant une 30aine de secondes, puis les requêtes recommencent à se bloquer, et c'est reparti pour un tour... pendant 3 jours...

Difficile de régler les performances du chat, apparemment elles dépendent du trafic qu'il y a sur le forum, durant ces 3 jours je l'ai déjà vu tenir plus de 200 personnes sans vraiment faire ramer le site (il était tard), puis je l'ai vu faire tout sauter avec 90 personnes... (il était pas très tard)

Grosse prise de tête en perspective...

Et là ça déconne plus: c'est les grandes vacances! La ptite famille revient en top priorité, et je ne vais malheureusement pas pouvoir m'occuper du site pendant de longues semaines...

Les semaines précédant les vacances auront été essentiellement consacrées à essayer de comprendre et résoudre ce problème de performance lié au chat, c'est trop con, il est pas si mal que ça ce chat, hormis ce GROS problème de performance... :(

Ah si, quand même, tous les bugs liés à la pagination dans les topics ont enfin disparu! (pas trop tôt!)

J'entreprends également la refonte du système de recherche pour le site. [lien]

En parallèle Hooper me demande la possibilité de pouvoir épingler des topics au-dessus des topics déjà épinglés dans les forums, cette fonctionnalité n'étant pas prévue par le système, je dois la mettre en place à la main.

A première vu ça fonctionne correctement, mais là erreur fatale (oui je sais: encore ;p), j'enfreins une des règles d'or du webmaster: "ne jamais implémenter une nouvelle fonctionnalité la veille d'un départ en vacances".

Les bugs liés aux "super-sticky" (comme l'impossibilité de créer un nouveau sujet!) vont ainsi durer pendant 15 jours, le temps que je revienne de Hongrie... (c'est con parce que c'était plutôt facile à résoudre, grrr... satanée règle d'or...)

Chaud chaud chaud! Bon ok, je sais que hooper veut relancer le chat pour l'anniversaire du site le 1er septembre avec un event spécial.
Depuis l'E3 j'ai optimisé comme un taré tout ce que j'ai pu pour que les requêtes soient plus rapides et moins nombreuses sur le site, je suis assez content de moi (40% de requêtes http en moins en moyenne sur chaque page!), même si je sais qu'il reste encore 2 systèmes de cache que j'ai pas encore implémentés pour les membres loggés et qui feraient peut-être une grosse différence.
J'ai même pris le temps de permettre l'intégration de soundcloud dans le chat (et dans le forum par la même occasion) en vue des blind tests prévus par les modos, et de mettre en place une actualisation automatique pour la bannière du haut.

"-T'inquiètes, le site va pas lever un sourcil..." tu parles! Il nous a pété à la gueule oui! C'est ça qui s'est passé!!! ... Poooourquooooiiiiiii?!!!! Bon, d'abord je vais aller pleurer dans mon coin pendant quelques jours...

Ok. Bon. Alors qu'est-ce qui s'est passé? Après tout ce que j'ai fait ça n'a rien changé? Et bien non, ça n'a quasiment rien changé. On positive: ça ne veut pas dire que ça n'a servi à rien, 40% de requêtes http en moins sur chaque page c'est bien, ça veut dire que le site pourra gérer un peu plus de trafic sur les pages "normales". Mais ça n'a pas du tout résolu le problème de performance du chat (on positive: il n'y a pas eu de réel problème au niveau des requêtes http et du serveur apache du coup, ce qui est lié à mes optimisations).

Cette satanée requête se bloque encore, et encore, et encore... et mysql étouffe, et il explose... toujours cette même requête... grrrrmmmllll...

Note: il y a aussi une autre requête qui rame, et qui est liée au messages privés, mais elle est beaucoup moins fréquente, et je pense qu'elle rame "naturellement", c'est à dire indépendamment du trafic qu'il y a sur le site, il semblerait que ça concerne les personnes qui ont plusieurs milliers de messages sur leur boite, ce qui est beaucoup, l'ouverture de leur boite peut alors prendre plusieurs 30aines de secondes, je verrai si je peux y faire quelque chose, sinon vous pouvez faire le ménage dans votre boite en attendant ;p

Mais là cette requête qui nous emmerde est liées aux droits d'accès sur le forum, et ce qui se passe c'est que dès que y'a un certain trafic sur le site, elle ne se met pas à ramer progressivement, elle passe de moins de 1 seconde de temps d’exécution d'habitude à plus de 30/60/120 secondes d'un coup.

C'est chelou. Le problème ne vient pas du chat, y a un truc qui couille, c'est lié au module qui gère les droits d'accès sur le forum, et c'est lié au trafic et à la taille de la base de données...

Avantage:
- Plus de problème de performance

Inconvénient:
- Utilisation d'un client externe

Ça voudrait dire pas de réelle intégration des membres du site dans le chat, pas d'avatars, pas d'accès au profil, pas non plus d'intégration des images, pas d'intégration soundcloud...

Hooper veut que le chat soit intégré entièrement au site, je pense aussi que c'est ce qui est le plus intéressant, pour le site et pour la communauté.

Ca veut pas dire qu'il faut pas faire de chat via IRC dans le futur, mais pour ce projet précisemment cette solution ne convient pas.

Ah ben là je dis oui! Pourquoi j'utilise pas des sockets dis-donc?
Après investigation ce serait effectivement la solution idéale pour résoudre notre problème de performance et de réactivité du chat.

Mais pour ça il faudrait que je trouve le bon module pour drupal qui utilise ce genre de technique, et pour l'instant ce module je l'ai pas trouvé... (pas pour drupal v6 en tout cas, qui est la version sur laquelle nous tournons pour l'instant) Et je vais vous le dire franchement: coder à la main un module de chat qui s'intégrerait dans drupal en utilisant des sockets, en s'assurant qu'il ne pose pas de problème de sécurité, c'est un peu chaud pour le pauvre noob que je suis... (en tout cas pour l'instant, je suis déjà en train de me taper des tutoriels en cascades... ;p)

Ca ne pourrait pas se faire rapidement, et Hooper aime bien quand les choses sont faites rapidement ;p

Alors va bien falloir faire quelque chose...
Bon déjà on a un chat qui peut tenir 120 connectés, après renseignements sur le web il semblerait que ce soit pas si mal que ça (vu la technique employée: php+ajax+mysql), mais c'est très insuffisant (on vise au moins 300, voir plus si dans le futur on fait des rooms).
Je suis persuadé que le chat pourrait tenir bien plus que 120 s'il n'y avait pas cette satanée requête qui venait foutre le bordel, même s'il faut admettre que cette solution reste limitée en terme de performances.

Il va donc sans doute falloir trouver un remplaçant à ce module, bon, c'est comme ça, c'est la vie, j'ai déjà quelques pistes, certaines plus compliquées que d'autres...

Si j'étais un Jedi j'te coderais tout ça avec node.js et socket.io ça enverrai du pâté et on en parlerait plus...

Dimanche en famille, Sherlock Holmes sur le canapé, puis j'me dit que je vais aller me coucher... puis finalement je décide de descendre à la cave pour voir si hooper s'était rendu compte que j'y étais pas... tu parles qu'il s'en était rendu compte, le site était down depuis plus de 4 heures!!!

Oh putain merde qu'est ce qu'il s'est passé??!! Ah oui... la vidéo "révélation" du hooper... Mais pourquoi mysql a explosé? ... Hein?... Ah merde quel con!!! C'est ma faute!!! J'avais fait des modifs sur mysql pendant le chat du 1er septembre en fin de soirée, et j'aurais du remettre certains anciens paramètres en place... Quel con... Si j'avais été là le site serait réapparu dans les 5 minutes... Quel con...

Ceci étant dit, il se serait sans doute quand même mis à sérieusement ramer, pendant une petite dizaine de minutes, le temps que les gens accèdent à la nouvelle vidéo, et encore une fois C'EST TOUJOURS CETTE MEME REQUETE A LA CON QUI SE MET A RAMER!!!!!

Et là pas de chat qui tienne, non, il y a bien un réel problème avec une des requêtes chargée de régler les droits d'accès au forum, c'est sans doute aussi lié à la taille de la base de données... ça peut aussi être lié à un bout de code, quelque part... c'est chaud...

Les droits d'accès sont au coeur de tout système de gestion de contenu impliquant des utilisateurs: pour chaque contenu il faut savoir si tel utilisateur, qui peut avoir tel rôle, peut ou non créer, ou modifier, ou supprimer le dit contenu, avec plus ou moins de granularité (telle partie du contenu et pas telle autre, en fonction de tel critère, etc...)

Pour le forum du hooper.fr j'utilise un couple de modules spécialement conçus pour gérer les droits d'accès sur un forum.

Ce système permet de:

• Gérer des modérateurs en fonction du forum, individuellement ou selon leur rôle.
• Gérer les droits d'accès (voir, créer, modifier, supprimer) des différents rôles (membre, modos...) en fonction du forum.
• Créer des forums privés accessibles uniquement à certains rôles (les modos).

Et il semblerait que ce soit l'utilisation de ces modules qui fasse ramer le site... fâcheux... pour le moins...

Disons mission délicate...

Bon, mes recherches m'indiquent qu'effectivement l'utilisation de ces modules peut poser des problèmes de performance sur des sites à gros trafic avec une grosse base de données.
Et devinez quoi? Le trafic du hooper.fr est parfois plutôt gros et la base de données contient déjà plus de 400 000 posts! C'est chauuuuuud...

Comment faire?
Le plus simple: éliminer ces modules.

Que se passe-t-il si on élimine ces modules?

• Le forum des modos devient accessible à tous
• Il faut reconfigurer les droits des modos et des membres, en ayant perdu la granularité par forum
• Il faut reconstruire les droits d'accès sur les 400 000 posts en priant pour que ça pète rien dans la base de données (note pour moi-même: penser à faire un backup avant)

Bon. La perte de la granularité peut-être on peut faire avec, ça veux dire que si un membre devient modo il devient obligatoirement modo de tous les forums, ce qui de toute façon est pour l'instant déjà le cas. On va peut-être aussi perdre quelques options, mais qui devraient être gérables avec un peu d'huile de coude.

Mais perdre la possibilité d'avoir un forum privé pour les modos, ça ça pose un vrai problème...

J'ai trouvé un possible module de remplacement, beaucoup moins complexe, qui se veut optimisé pour les performances, et qui pourrait permettre de gérer les droits en fonction des forums (et donc de créer des forums privés et des modos par forum).

Dans l'éventualité où j'arriverais à remplacer les anciens modules par le nouveau sans rien péter (trèèèès important), et que ça ne pose pas de problème au niveau de la modération, est-ce que ça résoudrait le problème de "la requête qui bloque"?

J'AIMERAIS BIEN!!!

En théorie la requête pour avoir les droits d'accès au forum devrait être beaucoup moins complexe, et donc plus performante. Ce que j'espère du plus profond de mon être, c'est qu'elle arrête de BLOQUER! je ne veux plus voir cette requête en rouge!

Pour optimiser une application qui demande des ressources on fait souvent appel à différents systèmes de mise en cache des données. Mettre en cache, ça permet en gros de pré-calculer un objet complexe et de rendre cet objet pré-calculé directement accessible et le plus rapidement possible à l'utilisateur pour lui éviter de faire le calcul ou d'avoir à le chercher.

Sur le site du hooper, en plus des diverses configurations de cache sur les services (http+mysql), plusieurs autres systèmes de caches sont en place:

• APC: il permet de "pré-compiler" une bonne partie du code php du site et de le mettre en mémoire vive, créant un réel gain de performance sur l’exécution du code.
• Memcached: drupal possède un système de cache pour toute une série d'éléments du site, il stocke ces caches dans la base de données. Memcache permet de stocker les caches de drupal en mémoire vive, permettant ainsi non seulement d'alléger la charge de mysql, mais en plus d'avoir accès aux données beaucoup plus rapidement (rien n'est plus rapide que la mémoire vive)
• Boost: spécifique a drupal et celui qui a sans doute le plus d'impact pour l'instant: il permet de mettre en cache sur le disque dur du serveur les pages entières du site pour les visiteurs anonymes.

En gros:

• Un visiteur anonyme veut accéder à la page hooper.fr
• Drupal regarde à quoi correspond cette page et quels éléments le code php lui demande d'afficher.
• Ok, il va chercher dans la base de données le texte et la date de la dernière annonce en date.
• Il va chercher dans la base de données l'image, le titre, la catégorie, la console, le résumé des dernières vidéos en date.
• Il va chercher dans la base de données les derniers commentaires, les utilisateurs associés, leurs avatars, le lien vers leur profil...
• ... etc... etc... jusqu'à récupérer tous les éléments de la page, tout en vérifiant bien sur que le visiteur anonyme a bien le droit d'accéder à ces données. Ça lui aura pris allez à la louche 500ms pour faire toutes ces requêtes, s'il a de la chance.
• Il affiche enfin tout ça au visiteur anonyme.
• Boost entre alors en scène, il sait qu'un visiteur anonyme vient d’accéder à cette page et s'est cassé le cul à tout calculer.
• Il sauvegarde alors cette page sur le disque dur.

• Un peu plus tard, un autre visiteur veut accéder à la page hooper.fr
• Boost le repère: "te prends pas la tête mec, tiens, j'ai ça pour toi..."
• Le visiteur accède alors à la page pré-calculée sur le disque dur, il ne passe PAS par la base de données! Et ça lui aura pris allez à la louche 10ms. (attention, je ne parle pas ici du temps de chargement du contenu en lui-même, html, images et tout ça, mais du temps qu'aura pris la requête à s'effectuer)

• Un peu plus tard, un autre visiteur veut accéder à la page hooper.fr
• Boost le repère...

Etc...Jusqu'à ce qu'il y ait une mise à jour sur la page en question (ex: nouveaux commentaires).
Le prochain visiteur anonyme se chargera alors de recalculer la nouvelle page, boost mettra le cache à jour... et ainsi de suite...

Le gain de performance est énorme (mis à part pour celui qui aura calculé la page pour tous les autres donc), il n'y a plus aucune exécution de code php pour afficher la page, il n'y a plus aucun accès à la base de données! (enfin presque, j'vais y revenir)

C'est en grande partie grâce à ce module qu'on a pu voir jusqu'à 1700 visiteurs online...

Donc je reviens sur ce "enfin presque" à propos de l'accès à la base de données pour les anonymes...
Le fait que boost élimine la communication avec la base de données et avec drupal empêche drupal de compter ces utilisateurs et d'afficher leur nombre en bas de la page forum. Ce qui est fâcheux.
Et le seul moyen que j'ai trouvé pour pallier à ce problème, c'est d'utiliser une gruge pour les anonymes qui fait que même s'ils accèdent à une page en cache ils vont aller "toucher" la base de données simplement pour signaler leur présence.
Ça créé un accès à la base de données, c'est dommage, mais le gain de performance reste très important malgré tout.

Mais je suis pas bien sur que cette "gruge" que j'ai mise en place fonctionne correctement, j'ai l'impression que le nombre de guests indiqué sur le forum a été revu à la baisse ces derniers mois, avant il était généralement 2 à 3 fois plus important que le nombre de membres connectés, et maintenant il est plus souvent à peu près équivalent. Et le trafic n'a pas spécialement baissé. Ce qui rend le phénomène étrange... et me fait dire que ma gruge ne doit pas être totalement efficace et ne comptabilise pas tout le monde... étrange... Faudrait que je regarde ça de plus près.

Pour info le nombre de membres et de guests indiqués sur le site correspond au nombre de personnes ayant demandé une page sur les 10 dernières minutes. (Il faut bien comprendre ici qu'on ne cherche pas à afficher le nombre de pages demandées par seconde mais bien le nombre de visiteurs actuellement en train de parcourir le site, et ce n'est pas si évident que ça à calculer. Si quelqu'un est en train de mater une vidéo par exemple, ou en train de prendre son temps pour lire un topic, il ne va sans doute pas faire de nouvelle requête sur le serveur avant un moment (surtout s'il est en train de mater une vidéo !), mais il est bien là. Drupal va donc au plus simple et fait cette "approximation" sur 10 minutes, qui correspondra "à peu près" à la réalité, et suffira à nous donner une idée du nombre de personnes actuellement en ligne.)

Drupal utilise une table spéciale dans la base de données appelée "sessions", elle contient les informations de base sur les utilisateurs en ligne: numéro d'utilisateur (ou anonyme), IP, date de dernière connexion... A chaque appel de page il va utiliser ces infos pour déterminer ce qu'il doit afficher (si c'est un anonyme j'affiche ça, si c'est un membre j'ajoute ça, si c'est hooper j'ajoute ça, en fait ces infos vont lui permettre de déterminer les droits d'accès... aaahhh les droits d'accès...). C'est donc le départ de tout: on demande une page (ou parfois un élément), on doit savoir qui la demande.

Et plus il va y avoir d'utilisateurs en ligne, plus il va y avoir du "trafic" sur cette table essentielle, ce qui peut avoir un impact sur les performances de mysql.

J'ai la possibilité de mettre cette table en mémoire vive, via le module drupal qui gère memcache. Et ça serait dommage de s'en priver ;p
En plus il semblerait que ce soit pas trop compliqué à mettre en place, et il y a peu de risques (le pire qu'il puisse arriver c'est que les sessions soient perdues, c'est à dire que tout le monde se retrouve déconnecté, ce qui va de toute façon arriver pour faire la transition)

Le seul inconvénient de mettre cette table en mémoire vive c'est que les sessions sont perdues si je reboot la machine ou si je reboot memcache, ce qui n'est donc à la fois pas très grave et pas très fréquent.

Et ça pourrait peut-être aussi permettre (à vérifier) à la gruge qui compte les visiteurs anonymes de ne plus être nécessaire.

Donc il faut le faire. Ça peut prendre une nuit... ou deux...

Et pourquoi Boost il mettrait pas en cache les pages des utilisateurs authentifiés?
Et bien parce que drupal considère qu'une même page va être différente d'un utilisateur à l'autre, et d'ailleurs son système de cache interne est très orienté dans ce sens, privilégiant ses caches essentiellement pour les anonymes.

Et il a en partie raison: chaque page est effectivement différente d'un utilisateur à l'autre, puisqu'en haut elle affiche l'avatar, le nom de l'utilisateur, et le nombre de messages dans sa boite privée.

C'est con hein? ;p En plus de ça lorsqu'un membre navigue dans le forum, il peut savoir si y a des trucs qu'il a pas encore vu par des petites indications "nouveau(x)". La présence ou pas du "nouveau(x)" sur une liste de topics dépend également de l'utilisateur.

Ou bien aussi le bloc d'activité récente du forum sur la page d'accueil, qui affiche aussi les posts venant du forum des modérateurs, uniquement s'il est vu par l'un d'entre eux.

Ou encore le bouton "modifier" sur un post qui appartient à l'utilisateur... bref, vous avez compris, un certain nombre de petits détails qui font qu'effectivement les pages sont différentes en fonction de l'utilisateur.

Il existe malgré tout une solution pour mettre en cache ces pages: authcache.

Là l'opération est un petit plus compliquée... Ce module permet la mis en cache en mémoire vive (via memcache) de pages entières pour les utilisateurs authentifiés, mais uniquement dans la mesure où les pages qui sont générées sont les mêmes pour tout le monde, en fonction de chaque rôle. Il propose ensuite un mécanisme pour ajouter par la suite (une fois la page chargée, via un peu d'AJAX) les éléments spécifiques à l'utilisateur ou au rôle en cours.

Ce qu'il faut donc faire c'est séparer le code commun à tous du code spécifique à l'utilisateur en cours, puis d'expliquer au module comment charger les éléments supplémentaires. Bon... Ça peut prendre un peu de temps... mais le gain de performance serait ENORME! Encore une fois, sur les pages mises en cache: quasiment plus de code à exécuter, quasiment plus d'appel à la base de données! Et le seul droit d'accès qu'on va demander c'est le droit d'accès à la page!!!

Sur des pages comme la page d'accueil ou la page forums (ces 2 pages constituant une très grosse partie du trafic), ça peut vraiment faire une différence sur les performances du site, m'est avis même que ça pourrait éliminer pour un bon moment les problèmes de ramage du site en cas d'augmentation du trafic, lors du lancement d'une vidéo surprise par exemple ;p (et même peut-être avec la "requête qui bloque" puisque la plupart du temps elle ne serait plus invoquée sur les pages principales).

Alors bien sur il faut d'abord régler ce problème de requête qui bloque, puis il faudrait mettre en place ces 2 systèmes de cache.

Alors je pourrais considérer le site comme "optimisé 1.0".

Alors je ne considérerai plus l'optimisation du site comme la priorité numéro 1.

Alors je pourrais enfin me concentrer sur le développement du site en lui-même.

Alors Hooper retrouvera un peu le sourire par rapport au site.

Et si le trafic augmente trop ou que la base de données devient trop gourmande, on ajoutera un 2ème serveur... et ce sera parti pour de nouvelles prises de tête... ;p

Parce que la sécurité, c'est important. ;p
Et c'est d'autant plus important que la popularité du site le rend particulièrement exposé aux vilains (essentiellement des robots mal intentionnés).

Oui, le site du hooper a subit et subit régulièrement des "attaques" depuis son lancement.
Mais rassurez-vous, rien qui n'ait pu faire de mal aux données.

Drupal mets la sécurité de son code en top priorité, et il est réputé pour ça, et je le mets à jour régulièrement. Vous ne pourrez pas exécuter de code ou injecter quoi que ce soit dans la base de données, pas la peine d'essayer j'ai tout verrouillé (vous ne pourrez même pas insérer d'html dans la base de données, c'est vous dire ;p). Vos mots de passe sont particulièrement bien sécurisés puisque même moi je n'ai pas moyen de les connaitre (ils sont grassement cryptés dans la base de données).

Alors on a bien eu des robots qui ont essayé de s'inscrire pour spammer à gogo sur les forums, mais ils n'ont pas fait long feu puisqu'une protection est maintenant en place pour les empêcher de s'inscrire (ce qui arrive une petite centaine de fois par jour!).

Après y a ceux qui veulent profiter d'un port ouvert sur le serveur pour s'incruster, pas la peine, tout est fermé (oui d'accord, ou presque ;p)

Y en a eu un aussi, qui s'est amusé à rediriger son nom de domaine vers le site du hooper, de façon à ce que par exemple si on allait sur sonnomdedomaine.com/forums ,ça affichait l'équivalent de hooper.fr/forums. Ce petit malin voulait profiter du ranking du site du hooper sur google pour augmenter celui de son nom de domaine. Pas facile de trouver la solution (qui se trouvait au niveau des DNS), mais le vilain fut vaincu.

Après y a les attaques de type DDOS, une protection a été mise en place an niveau d'apache, normalement plutôt serrée (je me suis moi même fait kické du serveur en testant le chat sur plusieurs fenêtres en même temps ;p), alors bien sur ça ne suffirait pas pour une attaque de grande ampleur, avec armée de robots et compagnie, pour ça il faudrait que le site soit réparti/dupliqué/synchronisé/sécurisé sur X serveurs (en fonction de la grandeur de l'attaque) façon wikipedia, youtube, twitter et compagnie, bon, il y a peu de chances qu'on subisse ce genre d'attaque, à moins que quelqu'un qui ait ce genre de moyen en veuille vraiment personnellement au hooper... ;p

Y a aussi ceux qui veulent "sucer" le site (oui bon "aspirer" le site ça marche aussi) et qui font ça comme des gros bourrins, en effectuant un max de requêtes possibles en même temps, et donc en engorgeant le serveur http. Bon, pour l'instant eux je les dégage à la main, ça n'arrive pas très souvent, je dois bientôt installer une nouvelle protection au dessus d'apache qui devrait entre autre pouvoir régler ce genre de problème. Ça reste encore à faire donc.

Et puis enfin y a l'attaque dite du "bourrinage de F5", compliquée à résoudre... (faudrait voir ce qui se passe sans ce bug de la requête qui bloque, parce que c'est principalement ça qui fout le bordel dans ces moments là pour l'instant, malgré ça ça reste un problème compliqué à résoudre, si quelqu'un à a une idée...)

Cela va sans dire que gérer la sécurité du site (et du serveur) m'a également bouffé pas mal de temps, ceci étant dit ce qui est fait n'est plus à faire et le site est aujourd'hui bien sécurisé, il me reste encore un outil ou deux à installer, ça devrait pas poser trop de soucis, et c'est pas hyper urgent. En l'état la sécurité du serveur est déjà satisfaisante.

Ce sont malheureusement les grandes victimes de cette année de prises de tête...
Et ça me chagrine ENORMEMENT... (c'est là que c'est le plus fun)

L'apparence et le design du site n'ont quasiment pas été modifiés depuis le lancement prématuré du site... et c'est très fâcheux... et oui ce fond bleu à rayures était censé être provisoire... ;p

J'ai juste eu le temps de faire en sorte que l'ensemble soit à peu près clair et lisible, avec une petit ambiance bordeaux/crème et des ptites icones de base, mais j'ai jamais pris le temps de passer un vrai gros coup de polish par dessus tout ça.

En plus de ça l'ambiance graphique mériterait d'être revue pour correspondre plus à ce que hooper désire, donc une ambiance plus steampunk.

Et la mise en page mériterait elle aussi d'être revue à pas mal d'endroits pour être plus pratique et plus utile, si possible en ayant une pensée pour les mobiles et autres tablettes.

Hooper est essentiellement préocupé par l'apparence de la colonne de gauche, qui ne lui convient pas (ce que je peux comprendre ;p), ainsi que par l'ajout de quelques éléments "dynamiques" qu'il attend depuis un moment déjà:
- un lakitu mis à jour qui clignote quand la vidéo arrive ou quand l'upload a foiré.
- les annonces qui défilent automatiquement si elles sont trop longues.
- LES AIGUILLES QUI DONNENT L'HEURE!!!

Ce sont peut-être des détails, mais ils peuvent ajouter à la personnalité du site.

Bref, y a encore du boulot à ce niveau là, va falloir s'y mettre...

C'est la priorité numéro 1 du Hooper.

Ca fait un moment qu'il a annoncé la section "fan-arts" (en partie victime du chat).
Et ça fait encore plus longtemps qu'il a annoncé la section "testeurs" (victime de tout le reste).

Ca craint...

Il va falloir s'occuper de ça très rapidement, en commençant sans doute d'abord par la section "fan-arts", qui risque d'être plus rapide à mettre en place (quoique...on croise les doigts ;p).

Au plus vite...

• Il reste encore quelques bugs gênants.
• Le module de sondage ne fonctionne pas correctement.
• L'intégration du nouveau moteur de recherche n'est pas terminée.
• Il manque encore quelques fonctionnalités.
• La réorganisation est toujours en cours...

(et si on pouvait "nettoyer" un peu le contenu ça serait pas plus mal ;p)

Étant données les nouvelles priorités, j'ai bien peur que le chat ne subisse pas de modification majeure avant un petit moment...

Ceci étant dit, il est fort probable que l'opération "optimisation 1.0" lui profite de façon non négligeable. A quel point? Je sais pas. Va falloir faire des crash-tests... ;p

En attendant que le chat soit plus performant, le streaming vidéo en direct par Hakhaasan c'est une super idée :)

Oooh j'en aurais bien d'autres des problèmes palpitants à vous faire partager, mais après ça risque de faire long... ;p

Au jour d'aujourd'hui, www.hooper.fr c'est:

• + de 2 millions de pages vues / mois
• + de 10 000 visiteurs uniques / jour
• + de 16 000 membres enregistrés
• + de 400 000 posts sur le forum
• + de 40 000 commentaires sur les vidéos

Et j'ai passé le plus clair de mon temps à faire en sorte que ces chiffres soient possibles... au détriment du reste...

Est-ce que les aiguilles du hooper.fr donneraient l'heure si le site était sorti un mois plus tard et si le trafic et l'activité sur le forum avaient été disons ne serait-ce que 2 à 3x moins importants?

La réponse est OUI, bien sur, sans aucun doute, c'est clair... et les nouvelles sections seraient sans doute là également.
Bon après j'dis pas qu'y aurait plus aucun bug, faut pas déconner non plus ;p

Est-ce que j'ai été lent pour résoudre tous ces problèmes?
La réponse est OUI, bien sur, sans aucun doute, c'est clair... Chaque détail est devenu important, et des détails dont je n'avais jamais eu à me préoccuper jusqu'à présent, noob que je suis, j'ai dû énormément me documenter pour être sur de pas faire de conneries (et malgré ça j'en ai fait des conneries), les tests étaient longs et douloureux (il fallait parfois attendre jusqu'à 4h du mat pour faire certains tests "délicats", il ne fallait rien casser...), la résolution de certains bugs étaient des casse-têtes sans nom, bref: j'ai beaucoup appris :)

J'aurais aimé que tout ça aille plus vite, j'aurais aimé pouvoir passer plus de temps à bosser sur le site, pour que tous ces problèmes de performances ne soient qu'un lointain souvenir, mais malheureusement c'est pas comme ça que ça s'est passé (l'apparition du chat n'est pas venu faciliter les choses ;p), et il nous reste encore un peu de chemin à faire avant d'en voir le bout, avant d'avoir un site vraiment solide, si possible dans les prochaines semaines.

Mais l'ombre du hooper plane et il va falloir aussi que je me concentre sur les nouvelles sections, puis sur la nouvelle apparence du site, et tout ça au plus vite...

- Tentacules activés !

Un dernier mot? MERCI! :)

Merci à cette communauté si active qui m'a tant fait transpirer, elle a su aussi me redonner du baume au coeur dans les moments difficiles :)

Et bien sur merci à Hooper, qui, malgré les coups de fouets, m'a donné toute sa confiance (et sa patience) pour m'occuper de son petit bébé, et quel bébé! J'ai BEAUCOUP appris! :)

A suivre d'ici quelques jours: une feuille de route précise récapitulant tous les problèmes à résoudre sur le site, les fonctionnalités à ajouter, par catégorie et par priorité, avant d'atteindre le status de "1.0 stable", si possible avec des échéances.

Cette feuille de route sera mise à jour régulièrement pour refléter l'état d'avancement du boulot, et du boulot va y en avoir! ;p