Le Hollandais Volant

Les limites de Blogotext

dolphine-mysql.jpg
Depuis hier soir mon site tourne sous MySQL au lieu de SQLite.
On peut dire ce qu’on veut de la simplicité de SQLite, parfois ça ne suffit juste pas. Je ne sais pas si ça vient de BlogoText qui est mal codé ou si SQLite est réellement beaucoup plus lent, mais je me pose des questions quand même. Peut-être que SQLite n’est pas adapté au web ?

Je ne suis pas le premier à être tombé sur ce problème : Idleman aussi avait son Leed sous SQLite avant de se rendre compte que ça n’allait pas…

SQLite tient la cadence avec ma base de données (700 articles, 9000 commentaires et 5000 liens) et ma fréquentation (25'000 pages vues par jour, donc une page toutes les 3 secondes en moyenne) : la page principale est générée en 0,07 seconde, ce qui reste parfaitement acceptable. Mais le serveur lui n’aime pas vraiment.
Voyez plutôt la charge CPU et la consommation de mémoire avant et après le changement :

lvechart.png
C’est très net…

Que faire alors ? Et pour BlogoText ?
Pas de panique si vous utilisez BlogoText : continuez.

BlogoText est fait de toute façon pour des sites pas trop grands. L’usage de SQLite est donc possible quoi qu’il en soit : à ma connaissance mon blog est le site tournant sous BlogoText avec la plus grande base de données (je reviendrai sur le cas de Sebsauvage) et la lenteur n’était pas catastrophique et à peine perceptible.

Par ailleurs, le passage de SQLite à MySQL se fait très simplement par le biais de l’import-export en XML. Si ça n’avait pas été le cas je n’aurais pas migré, je vous le dis.

BlogoText continuera à être développé sous SQLite et MySQL à la fois et vous pouvez toujours choisir celui que vous préférez ou que votre service d’hébergement propose.

Le cas du blog de Seb : on m’a demandé pourquoi : il tourne aussi sous Blogotext, il a dix fois plus de visites que moi et beaucoup plus d’articles que moi aussi. Et il est sur la version texte (1.x) de BlogoText. Comment se fait-il que son site soit super rapide ?
La raison unique est qu’il n’a aucun commentaire. C’est tout.
L’affichage d’un seul article engendre la recherche dans l’intégralité des commentaires. Donc 10000 commentaires = 10000 parsages de fichiers. Aucun commentaire = aucun parsage de fichier.

image de Gerald Carter

ÉDIT : suite à quelques tweaks et l’instauration des bons indexes (grâce à vos commentaires), je suis de nouveau sous SQLite, mais cette fois c’est très rapide.