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.

old-indian-chief.jpg Hier j’ai dû mettre le site en maintenance quelques minutes pour mettre à jour Blogotext (et migrer sous MySQL en même temps — j’y reviendrais prochainement).
Pour qu’un visiteur qui arrive à ce moment là ne rencontre pas tout un tas d’erreurs quand j’envoie mes fichiers par FTP ou que je lance mes scripts, j’utilise ce petit bout de code Apache :

RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteCond %{REMOTE_ADDR} !255.34.56.78
RewriteRule .* http://lehollandaisvolant.net/maintenance.html [L]

À placer dans le fichier .htaccess de la racine du site, après avoir remplacé l’adresse IP de la seconde ligne par la vôtre.

Ce que cela fait ligne par ligne :
Ligne 1 : pour tout accès à un fichier autre que maintenance.html ;
Ligne 2 : et pour toutes les IP sauf 255.34.56.78 (la vôtre donc) ;
Ligne 3 : rediriger sur la page maintenance.html.

La ligne 1 permet simplement d’éviter une redirection en boucle, très important : le hit sur maintenance.html ne doit pas générer de redirection sur maintenance.html
Très bourrin comme méthode mais ça marche.

Cela vous permet à vous d’accéder à votre site normalement et aux autres de ne pas interférer et d’être au courant de ce qui se passe : la page maintenance.html contenant évidemment un message avec éventuellement un lien vers un autorblog du site.

image de Mharrsch