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).
31 commentaires
Il y aurait possibilité d'avoir le système de pagination pour la version texte ? Ou de fournir des explications pour en faire une ?
Donc je résume SQLite : c'est lent, pas installé partout... tu as encore des atouts sous la main ? :)
@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.
Lent ? Je ne trouve pas la version actuelle si lente que cela !
@Le Hollandais Volant : Je crois qu'il y a un ptit pincement avec le flux RSS http://lehollandaisvolant.net/rss.php?full
@PostBlue : merci, c’est corrigé :)
Cool, il y a de bonnes idées dans le design !
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.
@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…
Et PostGreSQl ? Il a un peu la cote non ?
@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.
@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.
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.
Merci pour les conseils !
Ah, chez moi le bouton "au hasard" est bien un curseur normal pour un lien : la petite main là.
@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 :)
@Le Hollandais Volant :
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 ^^@Guenhwyvar : je vais l’ajouter.
Moi, je m'interroge...pourquoi un chaton pour illustrer un migration Blogotext :p
Bonjour,
En cherchant un article disparu, je suis tombé sur une 404. Une erreur s'est affichée en haut de l'écran. Regarde: "Notice: Undefined offset: 0 in /home/timo/public_html/inc/them.php on line 261"
Voir ici: http://lehollandaisvolant.net/?d=2012/06/07/14/23/15-vous-navez-pas-le-droit-de-ne-pas-aimer
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=MEMORYPRAGMA synchronous=OFF
PRAGMA default_cache_size = 10000
@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é ?
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/
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.
J'attends tes retours de test ;-)
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…).
Hmm, tu utilises bien les transactions quand même ? :-?
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 ?
Pour les SELECT ça ne sert à rien mais pour les INSERT et UPDATE ça change tout (enfin, pour les requêtes par lots). Voir http://www.sqlite.org/faq.html, point 19 et http://www.sqlite.org/speed.html. Évidemment si tu ne fais que quelques INSERT par-ci par-là, le bénéfice est quasi nul.
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.
Et merde l'erreur 500 du serveur qui a re-posté mon commentaire, désolé.
@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 !