Rien de vraiment nouveau, si ce n'est au niveau technique.  Ca concerne toutes les images, fichiers sons et vidéos chargés dans les blogs. Voici de nouveau un article destiné aux gens interessés par cet aspect.

Déjà, tout le processus est devenu modulaire. Chaque opération : retouche, et insertion dans la base de donnée,  peut être fait soit par une fonction locale, soit par un webservice sur un autre serveur.

Ensuite, les fichiers sont immédiatement envoyés sur un autre serveur (images1.vefblog.net en ce moment) qui s'occupe d'afficher toutes les images dans les navigateurs. Pour la suppression, c'est la même chose ; tout est géré grâce à des services web. Cette syncronisation en temps réel (mais sans attente du client) évite en plus de coûteuses syncronisations totales chaque nuit. En cas d'erreurs, des ficheirs log permettent de retenter ces opérations plus tard.

Enfin, un service résident (un démon, souvenez vous) gère maintenant la file d'attente de retouche des fichiers. Cela signifie que quand il est lancé, deux fichiers ne peuvent pas être traités en même temps ce qui évite des surcharges du serveur à cause de ça. Par contre, le service commence par les fichiers de plus petite taille, et met les plus gros à la fin.

Si vous chargez une petite photo, vous attendrez que la place se libère puis votre photo sera traitée ; à priori ca ne changera pas beaucoup de avant - sauf si le serveur était déjà en train de retoucher une grosse vidéo par exemple, auquel cas vous attendrez un peu.

Par contre si vous chargez un gros fichier, vous attendrez qu'il n'y ait aucun plus petit fichier que le vôtre à traiter. En théorie, en heure d'affluence le temps peut donc être repoussé mais la plupart du temps ca ne changera pas grand chose.

C'était devenu necéssaire avec l'autorisation des gros fichiers images, son et vidéo (20Mo pour le moment). En plus, je saurais quand la file d'attente devient grosse, et quand il y aura trop de fichier à traiter nous prendrons un nouveau serveur rien que pour ca, grâce à cette nouvelle modularité...

Quelques shémas des différentes possibilités de cette nouvelle modularité : 

Ancien système 

 Système avec services Web et syncronisation

Avec le service de gestion des files d'attente

Plusieures heures à chercher pourquoi l'appel write() faisait parfois planter le service des stats écrit en langage C. J'ai du éxécuter le programme avec gdb pour comprendre ce qui se passait.

Parce que il faut d'abord faire ignorer le signal SIGPIPE pour avoir une chance de traiter l'erreur générée par write() ou send(), et de fermer la connection. Sinon, le programme plante sans mot dire.

Au début, éxecuter : 

signal (SIGPIPE, SIG_IGN);

A encadrer.. 

Sinon, la bonne nouvelle c'est que ce service qui gère toutes le comptage des visites en temps réel, tient le choc même avec plusieurs millions de visites et de blogs (dans ce cas il prend 250Mo de RAM, mais reste très disponible et rapide). Je viens de simuler ca sur mon PC..

Bon, un article pas pour tout le monde, mais je vais essayer de temps en temps de faire ici des articles techniques sur mon expérience grâce à Vefblog. 

En tout cas, celui-ci peut dépanner du monde.. 

Annonce 

Voici le retour de la recherche dans les articles et les commentaires, beaucoup plus rapide que avant.

Je n'utilise plus le même système pour la recherche, voici donc le nouveau comportement :

• Les nouveaux articles et commentaires, ou les articles modifiés ne sont pris en compte que le jour suivant
• Rendre un blog discret ou le remettre public, de même que effacer un article ou un commentaire est pris en compte immédiatement pour la recherche en page d'accueil

Suite technique de l'article

Je n'utilise plus les index fulltext de mysql, qui mettaient à genoux le serveur et ne permettaient pas une recherche rapide de texte + critère (comme par exemple du texte dans un blog précis)

J'ai découvert sphinx, un moteur de recherche de texte puissant et rapide. Je l'ai donc installé sur le serveur et pris en compte par vefblog.

Il y a deux index : un pour les articles et l'autre pour les commentaires. Chaque nuit, les index sont recréés avec l'option -rotate de indexer. Pour le moment je n'ai pas implémenté les tecniques de delta des index, car un article de n'importe quelle date peut etre modifié. La création des index prend une dizaine de minutes.

Pour la prise en compte automatique des blogs discrets, effacés, des articles en brouillons ou postés etc, j'utilise la commande de l'api php UpdateAttribute. Ainsi, un blog ou un article qui vient d'etre effacé, n'est plus pris en compte même dans le nombre d'éléments trouvés.

Dans la recherche, je fais d'abord une requete sur 0 éléments afin d'avoir le nombre total que j'affiche ; cela me permet aussi d'avoir le nombre de pages et de gérer les liens. Puis je fais une requête sur 10 éléments en fonction de la page affichée, comme sous mysql. Je fais ensuite une requete mysql sur un in ( ) des ids trouvés par Sphinx, que je re-trie ensuite dans l'ordre des indices trouvés par Sphinx car sinon mysql me remet tout dans le désordre. Puis les articles et commentaires sont affichés de façon habituelle.

 Grâce à ce système, Vefblog a maintenant un moteur de recheche performant.

Il y a eu un plantage généralisé mardi 05 février 2008, de 15h44 à 22h43 (quand j'ai traité le probème). Vefblog renvoyait une page blanche, certains blogs plantaient mais pas d'autres. Apparemment on pouvait mettre des commentaires, mais pas écrire d'articles.

La raison est technique, c'est dû à un bug très rare d'un module utilisé pour rendre plus rapide. J'ai fais une mise à jour du serveur, ainsi que de ce module en particulier.

Je met aussi un reload automatique du serveur web toutes les 4 heures, ce qui suffit pour corriger le problème quand il se produit.

Ce bug est le même que celui-ci:

http://pecl.php.net/bugs/bug.php?edit=3&id=9745

 et celui-ci:

http://pecl.php.net/bugs/bug.php?id=10653

Espérons que la mise en jour réglera définitivement le probème ; j'en ferais régulièrement pour prévenir.

Dans le même genre de poisse, dû à une saturation de courte durée ce soir, je désactive de nouveau la recherche de texte. Je vais essayer de trouver une  autre solution que mysql pour la recherche dans les articles et les commentaires, car ce n'est vraiment pas bien pris en charge..

Article pour les geeks uniquement.. 

Voici une info qui ne change rien au résultat final : la semaine dernière, je me suis amusé à refaire complètement le démon (service résident si vous préférez) qui s'occupe de prendre en compte toutes les visites des blogs de l'accueil, en langage C.

En effet, avant il était en  php, mais ce service doit être le plus rapide possible car :

• il est très sollicité,
• il doit accepter l'information sur la visite et rendre la main le plus vite possible pour ne pas accumuler les processus apache qui attendraient.

Son rôle exact est de retenir quelles sont les visites actives, c'est à dire les visites qui ont eu au moins un hit depuis moins de 30 minutes ; pour chacune il retient le nombre de hits, l'heure du début et l'heure du dernier hit. C'est lui qui est interrogé pour connaitre le nombre de visiteurs actuellement sur un blog ou l'accueil. Pour le contacter, il écoute sur un port tcp local et sur une socket unix.

Une visite est une adresse ip sur un blog (ou l'accueil). Chaque début de visite et chaque fin de visite (30 minutes après le dernier hit), il envoie l'info à un autre démon (stat 2ème  niveau) qui se charge de le rentrer dans la base de données. Cela permet de ne pas charger la base de donnée en lecture et écriture à chaque hit sur une page.

J'ai fait un programme en C assez sophistiqué qui gère très bien tout ca. En particulier, il gère:

• une organisation de la mémoire par buffer, afin d'éviter de reserver trop de mémoire dès le début sans savoir, et d'éviter aussi des malloc constants à chaque nouvel élément à retenir. La réservation de la mémoire se fait par tranche (par exemple 100) d'éléments à retenir (blogs, visites, index, listes de timeout, etc..)
• une gestion des index pour retourver rapidement un blog ou une visite, en utilisant deux niveaux de hash.

Cette nouvelle version du service de stat a été longue à déboguer (forcément, un programme en C..) et a tourné plusieurs jours en parallèle du premier afin de le tester. Il est en production depuis avant-hier, avec succès...

Ca m'a fait plaisir de refaire un peu de C. C'est 4 fois plus long à développer que le php, mais très efficace, et intellectuellement plus satisfaisant.Ca change un peu..