Je viens de passer le site sous Blogotext SQlite pré-alpha-0.0.0.2. Cette version utilise SQLite avec PDO.
C’est plutôt lent (PDO est beaucoup plus lent que les fonctions classiques de traitement comme sqlite_query(), etc.)

Le problème c’est qu’actuellement Blogotext analyse plusieurs fois la base de données. Je vais voir si je peux faire en sorte qu’il ne la parse qu’une seule fois, et si je peux optimiser tout au niveau même de SQLite : en ajoutant des index sur les champs de la BDD (je ne connais pas encode trop ça *me va se taper de la littérature…).

On peut dire ce qu’on voudra de MySQL, mais c’est quand même beaucoup plus rapide que SQLite… (d’un facteur 20 environ, avec la BDD que j’ai).
La page actuelle se génère en environ 0,2 seconde.

Enfin bon, les commentaires sont réactivés et vous avez quelques nouvelles fonctions sur mon blog : en bas de la page les liens de pagination ; en bas de chaque article : les tags sont ajoutés ; sur le côté droit il y a un bouton « un article au hasard ».
Et j’ai retouché un peu le thème (qui passe mal sous les mobiles, je suis au courant).

Image de Abdulmajeed Al.mutawee

31 commentaires

gravatar
julien a dit :

Il y aurait possibilité d'avoir le système de pagination pour la version texte ? Ou de fournir des explications pour en faire une ?

gravatar
Gilles a dit :

Donc je résume SQLite : c'est lent, pas installé partout... tu as encore des atouts sous la main ? :)

gravatar
Le Hollandais Volant a dit :

@Gilles : SQLite est pratique.
Et la lenteur n’est pas perceptible sur des petits sites.


@julien : Tout est techniquement possible. Mais avec la version texte, les performances deviennent catastrophique. Il faut mieux adapter le petit calendrier et trier par mois plutôt que par page.

gravatar
Kevin a dit :

Lent ? Je ne trouve pas la version actuelle si lente que cela !

gravatar
Arthur a dit :

Le gros avantage d'utiliser PDO, c'est que si jamais tu venais à passer à MySQL, PostgreSQL, ou autre, tu ne devrais pas y passer une dizaine d'années. :)
Beau boulot, BTW.

gravatar
Le Hollandais Volant a dit :

@Arthur : yep je sais. J’ai déjà pratiquement créée une compatibilité entre Mysql et Sqlite. Juste un paramètre à changer dans les config et on bascule de l’un à l’autre.

Mais la compatibilité n’est pas totale…

gravatar
Arthur a dit :

@Gilles : Oui, j'aurais même ance à dire qu'il est meilleur, vu qu Oracle se fout pas mal des normes... Mais MySQL est quand même le plus pratique : Dispo partout, majorité des apps PHP l'utilisent, installation simple (WAMP, LAMP, etc.) .. La popularité joue beaucoup.

gravatar
Arthur a dit :

@Gilles : Oui, j'aurais même ance à dire qu'il est meilleur, vu qu Oracle se fout pas mal des normes... Mais MySQL est quand même le plus pratique : Dispo partout, majorité des apps PHP l'utilisent, installation simple (WAMP, LAMP, etc.) .. La popularité joue beaucoup.

gravatar
Guenhwyvar a dit :


Le problème c’est qu’actuellement Blogotext analyse plusieurs fois la base de données.


C'est quoi que t'appelles analyser ? Si tu veux dire qu'y a plusieurs requêtes, ça me parait normal. Pour une page d'article, par exemple, à vue de nez j'en vois trois : une pour constuire le calendrier, une pour l'article (date, titre, contenu, tags…), et une pour les commentaires (que tu peux sûrement intégrer à la précédente avec une jointure). Et y'en aura une de plus quand t'auras remis l'encart des derniers commentaires.

Y'a des jolis trucs, dans ton thème (j'aime bien les cadres de tags, de réponse et de lien), mais tes ombres sont un peu trop floues, et le footer est moche (les couleurs vont franchement pas ensemble).
Ah, et change le curseur sur ton lien d'article au hasard, là on voit pas que c'est un lien.

gravatar
Le Hollandais Volant a dit :


Y'a des jolis trucs, dans ton thème (j'aime bien les cadres de tags, de réponse et de lien), mais tes ombres sont un peu trop floues, et le footer est moche (les couleurs vont franchement pas ensemble).
Ah, et change le curseur sur ton lien d'article au hasard, là on voit pas que c'est un lien.



Merci pour les conseils !
Ah, chez moi le bouton "au hasard" est bien un curseur normal pour un lien : la petite main là.

gravatar
Gilles a dit :

@Arthur : Bah je vois de plus en plus d'hébergeur le proposer, et certains scripts semblent compatibles.
Le niveau de popularité n'est pas comparable avec MySQL mais bon, c'est juste pour pousser timo à sortir un script qui ne marche pas que chez 10% des hébergeurs :)

gravatar
Guenhwyvar a dit :

@Le Hollandais Volant :


Ah, chez moi le bouton "au hasard" est bien un curseur normal pour un lien : la petite main là.


Alors :
— avec Firefox : curseur flèche, lien souligné au survol ;
— avec Chrome et Epiphany : curseur flèche, lien pas souligné au survol ;
— avec Opera pas du tout à jour : curseur main, lien pas souligné au survol, mais reste de la page tout cassé (ouais, il est vraiment pas à jour) ;
— avec IE : alors là…

Comme quoi, un petit cursor: pointer; dans ton CSS, ça ferait pas de mal ^^

gravatar
Pascal a dit :

Moi, je m'interroge...pourquoi un chaton pour illustrer un migration Blogotext :p

gravatar
GoustiFruit a dit :

Euh les petits lapins, je viens de tomber sur une astuce qui permet d'améliorer la vitesse de SQLite, l'avez-vous déjà essayée ?

PRAGMA temp_store=MEMORY
PRAGMA synchronous=OFF
PRAGMA default_cache_size = 10000

gravatar
Le Hollandais Volant a dit :

@GoustiFruit : Ça c’est très intéressant ! Merci !
Je dois mettre ça où ?

La première ligne semble mettre les éléments en RAM au lieu du disque : n’a-ce pas de conséquences sur la fiabilité du système ?
C’est quoi le délai pour que le fichier sur le disque soit synchronisé ?

gravatar
GoustiFruit a dit :

Ce sont des commandes type SQL, donc à saisir directement dans la console, ou à passer selon le langage que tu utilises comme une requête SQL.
D'après ce que j'ai compris, par défaut SQLite a un mécanisme qui force l'écriture des données sur le disque dur avant de passer à la suite, histoire d'éviter les pertes par ex. en cas de coupure de courant. C'est ce qui ralentit énormément le bousin. En passant "synchronous=OFF", ça désactive ce mécanisme: plus rapide mais moins "secure". Ensuite "temp_store=MEMORY" agirait en quelques sortes comme un cache en RAM, et default_cache_size, et bien... définirait la taille de ce cache.

Trouvé sur developpez.com (http://www.developpez.net/forums/d258442/bases-donnees/autres-sgbd/sqlite/lenteur-sqlite/) et plus de détails sur http://www.rkblog.rk.edu.pl/w/p/sqlite-performance-and-django/

gravatar
Le Hollandais Volant a dit :


ou à passer selon le langage que tu utilises comme une requête SQL.


Ok, c’est ça qui me fallait savoir :-)

Merci pour les liens !

Oui j’ai bien compris qu’il faut là faire un compromis entre la rapidité et les potentielles pertes. Ceci dit, mon site n’est pas populaire au point d’avoir à écrire des données toutes les secondes, donc je peux activer ça sans soucis.

gravatar
GoustiFruit a dit :

J'attends tes retours de test ;-)

gravatar
Le Hollandais Volant a dit :


PRAGMA default_cache_size = 10000


Cette option est dépréciée.

Bon, d’après mes tests : ça ne vaut pas le coup d’activer ça dans Blogotext.

– pour l’affichage des pages : aucun changement visible
– le gain est là uniquement dans ma page de maintenant, lors de l’import de grandes quantités de données à partir d’une base XML : 25% de gain environ (parce qu’il y a un grand nombre de requêtes, mais j’ai trouvé un moyen en PHP pour palier à ça).

Je remarque quand même qu’avec ces deux options, les pages se chargent entre 13 et 28 ms chez moi, alors que sans, c’est beaucoup plus régulier (entre 22 et 26 ms) sur 10 essais de suite.

Je sais pas si c’est que ma config ou autre mais là, le changement est pratiquement nul (99% des requêtes SQLite sont des lectures donc ça ne vaut pas le coup quoi…).

gravatar
GoustiFruit a dit :

Hmm, tu utilises bien les transactions quand même ? :-?

gravatar
Le Hollandais Volant a dit :

Nope.

Pour les entrées multiples du veux dire ?
Non, j’utilise PDO, donc avec les requêtes préparées et les « ? », je ne peux en mettre que 1000 (limitation interne à PDO). donc que j’utilise les transaction et plusieurs lignes dedans, ou une méga-requête de 100 inserts à chaque fois, ça ne change rien.

Mais pour les requêtes simples ("select", "insert" simple) , les transactions, ça sert à quoi :-o ?

gravatar
bohwaz a dit :

Hello, oui utilise des transactions pour les insert et update à la suite (tout ce qui écrit dans la DB en fait), et il est aussi conseillé de ne pas mixer des SELECT au milieu des écritures.

Donc genre :

db->exec('BEGIN');
db->exec('INSERT INTO machin...');
db->exec('INSERT INTO machin...');
db->exec('INSERT INTO machin...');
db->exec('END;');

Et hop. Au niveau de l'écriture ça sera très rapide (j'insère plusieurs millions de lignes en une transaction en quelques secondes moi).

Pour la lenteur en lecture, il y a masses de trucs qui peuvent interférer. D'abord : ne pas utiliser SQlite2, mais la version 3. La 3 est plus rapide et apporte pas mal de trucs intéressants. Ensuite : faire des index, des index, des index. Et enfin : les utiliser, les utiliser, et encore les utiliser. Par exemple un JOIN sera très très lent sans index. Il n'est pas normal qu'une requête sur une base de quelques Mo seulement soit lente en SQLite3. C'est un moteur très efficace, à moins de faire des choses vraiment tordues.

gravatar
bohwaz a dit :

Et merde l'erreur 500 du serveur qui a re-posté mon commentaire, désolé.

gravatar
Le Hollandais Volant a dit :

@bohwaz : pour l'ecriture c'est bon là :-).

Sinon pour les index, je confirme, ça change vraiment tout : environ moitié moins lent avec de index que sans !

Les commentaires sont fermés pour cet article