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

158 commentaires

gravatar
Julien et Nel a dit :

C'est sans doute pour ça que j'utilise disqus pour "UAG" et pas un système de commentaire interne.

Ceci m'évite d'avoir une surcharge aux niveaux des commentaires sur le long terme pour le moment.

Sqlite et les fichiers textes sont adaptés à un petit poids de données, mais il y a une limite ...

Sqlite a été penser pour des applications à la base et pas pour les sites, enfin je crois.

gravatar
mezzer a dit :

T'as plus qu'a passer sous nginx / php-fpm :)

gravatar
tony a dit :

Avais tu activé le mode WAL de SQLite ? Pour mon app cela changea tout.

gravatar
Gilles a dit :

Pas mal Disqus, ciomme ça ils te fliquent aussi bien que Facebook sauf que si tu désactive le bouton FB via Ghostery, bah tu peux surfer sur un site sans souci, alors que si tu bloque Disqus, pas de commentaire.
Trop bien Disqus pour la liberté sur le Net !

gravatar
Sbgodin a dit :

La grosse différence entre SQLite et Mysql est que Mysql maintient un processus dédié à la gestion des accès. Les fichiers de la base de données (structure, données, index) ne sont ouverts qu'une seule fois. Le contenu des données est mis en cache. Au prix d'une certaine complication de la gestion de la base, de la consommation en parmanence d'un peux de ressouces on a une meilleure réactivité.

gravatar
Le Hollandais Volant a dit :

@tony : Je viens de tester en local : aucune différence.

@Julien et Nel : –1

@Gilles : +1

J’utiliserais pas Discus. Autant utiliser les commentaires Facebook, ça revient sensiblement au même.
Je ne veux pas de services externes chez moi. Si le site devient effectivement trop grand et si la gestion de commentaires devenait problématique, je passerais une partie du site en statique, c’est tout.

On a vu le bordel que c’était quand le plugin FB était innaccéssible il y a quelques semaines : des tonnes de sites de répondaient plus. Non merci, je ne veux pas de ça ;-).

gravatar
Rady a dit :

Intéressant de voir la difference.
Je n'ai jamais utiliser SQL lite pour le moment mais c'est bon de voir quelque feedback.
Par curiosité tu as sorti comment tes graphiques ?
Pour Discus il est vrai que niveau liberté... il nous faudrait le meme en libre pour l'installer sur un deusieme server dédier à cela :)

gravatar
Le Hollandais Volant a dit :

@Rady : mon hébergeur fournit un outil intégré à CPanel pour voir ça.

Mais j’insiste : SQLite n’est pas mauvais, c’est juste qu’il me semble très mauvais dans la gestion de tables multiples et de jointures, de relations entre les bases…
Sur mon ancien soft de partage de liens, Linx, c’était extrêmement rapide : 7 millisecondes pour trier 2000 liens.

gravatar
MutoKenji a dit :

Je ne comprends pas la fin de ton post.
"L’affichage d’un seul article engendre la recherche dans l’intégralité des commentaires. Donc 10000 commentaires = 10000 parsage de fichiers. Aucun commentaire = aucun parsage de fichier."

??
Je n'ai aucune idée de ce à quoi ressemble une base de donnée de blog, mais les commentaires ne sont pas indexés par article ?

gravatar
Le Hollandais Volant a dit :

@MutoKenji : ils sont dans deux tables différentes. Donc ayant un article, il faut ensuite chercher les commentaires associés, et ça, ça se fait par comparaison. Qu’on ait une BDD ou non, il faut bien que le système compare chaque commentaire pour voir si il correspond.

gravatar
MutoKenji a dit :

Hum... Je ne suis pas sûr qu'on se comprenne car j'ai l'impression que c'est la base d'une base de données.

C'est le principe d'un index :
Tu vas faire "afficher l'article d'id X. et selectionner tous les commentaires où id_article = X. ça va utiliser l'index et donc te ressortir tous les commentaires correspondant à cet article là.
Ça ne parse pas tous les commentaires, juste l'index."

gravatar
GoustiFruit a dit :

@MutoKenji : Je ne comprends pas non plus LHV !
Un simple "SELECT * from tbl_comments WHERE article_id = xxx" devrait être quasi instantané pour une si petite BDD. Excuse-moi LHV mais 9000 commentaires pour 700 articles, ça fait du 12 commentaires par article, il n'y a aucune raison que ça bouffe les ressources que ça bouffe sur ton serveur !

gravatar
TD a dit :

@Le Hollandais Volant : si tu ne veux pas utiliser les services externes, y aurait-il la possibilité d'utiliser un service « externe interne » ? Je veux dire par là héberger toi-même un truc à la Disqus et l'utiliser avec Blogotext. Je ne sais pas si ça existe (et ça m'intéresse), mais ça en vaudrait la peine selon moi (rien que pour commenter des pages statiques par exemple).

gravatar
Silversthem a dit :

ça y est, tu es passé du côté obscur de la force...
Sérieux, les fichiers c'est pas mieux ?

gravatar
Le Hollandais Volant a dit :

@Silversthem : trop lent, vu comme c’était fait dans BT.
Il aurait fallu changer trop de choses pour que ce soit rapide.

Stocker les commentaires dans des fichiers de la forme id-articls.id-commentaire.txt, comme dans PluXML.
J’avais essayé, crois moi, mais c’est trop de boulot et il aurait fallu refondre tout le code.

(mais je n’exclue pas de remettre la possibilité d’un stockage sous forme de fichiers textes dans le futur, en évitant les erreurs d’avant).


@GoustiFruit : je peux essayer avec un index sur les "id_articles" dans la table des commentaires… Mais plusieurs commentaires auront la même valeur. C’est pas une problème ça ?

Les 12 commentaires par articles ? heu, non c’est plutôt 25~40. (au début mon blog avait les commentaires fermés).

La requête c’est ça :
SELECT * FROM commentaires WHERE bt_article_id=? AND bt_statut='1' ORDER BY bt_id

Ça peut venir du type de variable ? Perso je me fais pas trop chier : pour le coup c’est du BIGINT pour les ID, au format YYYYMMDDHHIISS.

gravatar
MutoKenji a dit :

C'est sûr qu'il te faut un index sur bt_article_id dans la table commentaires.
Il n'y a aucun problème au fait que plusieurs articles auront le même bt_article_id, ne confonds pas un index et une contrainte d'unicité.

Là, sans index, comme tu l'as dit, ta requête doit parcourir tous tes articles et regarder pour chaque l'article ID.

Un index, c'est en gros un tableau id_article => liste de commentaires.
Donc ta requête, au lieu d'aller voir dans l'id_article dans tous les commentaires, elle va aller voir dans l'index quels sont les commentaires associés à ton article, c'est vraiment beaucoup plus rapide et c'est la bonne pratique ici.

gravatar
tester a dit :

il y a aussi le fait que tu ne poses pas de LIMIT. Tu peux par exemple créer un champ dans la table article qui s'incrémente au fur et à mesure qu'un commentaire s'ajoute. Après quand tu fais un select sur l'article tu récupères le nombre de commentaires pour fixer la limit sur la requète "commentaire"...ça évite de parcourir toute la table à chaque fois.

gravatar
Le Hollandais Volant a dit :

@MutoKenji : ok, je viens de tester en local. Aucune différence.
J’ai ajouté :
CREATE INDEX art_id ON commentaires ( bt_article_id );
CREATE INDEX bt_date ON articles ( bt_date );

Résultats :

index.php page (accès seulement à la table des articles) :
SANS INDEX : 0,21s
AVEC INDEX : 0,19s

liste 25 articles admin (accès seulement à la table des articles) :
SANS INDEX : 0,06s
AVEC INDEX : 0,03s

liste commentaires (liste les articles pour les titres des articles de chaque commentaires):
SANS INDEX : 0,25s
AVEC INDEX : 0,25s

Article simple (article + ses commentaires):
AVEC INDEX : 0,28s
SANS INDEX : 0,31s

gravatar
Le Hollandais Volant a dit :

@tester : C’est déjà le cas, depuis un moment et justement pour des questions de performances.
Le nombre de commentaires d’un article est déjà enregistré avec l’article.
L’ajout d’un commentaire nécessite effectivement une requête dans la table des article, mais lors de la lecture (90% du temps) il n’y a pas de requête vers les commentaires.

gravatar
MutoKenji a dit :

Fais un EXPLAIN de ta requête pour voir si elle utilise l'index que tu viens de créer.
Mais a priori, c'était une chose qui manquait.

Après, je sais pas trop, on a assez peu d'éléments sur l'ensemble du truc, j'aime pas trop parler sans trop savoir de quoi il s'agit.
Ca peut venir de plein de trucs différents.

Et sinon, cette histoire de nombre de commentaires avec un LIMIT, je suis pas sûr que ce soit une bonne pratique ?

gravatar
Anon a dit :

@Le Hollandais Volant :
Le limit sur les commentaires, je pense pas que ce soit une bonne idée.
Par contre peut être remplacer le WHERE par un LEFT JOIN ? J'ai déjà eu de beaux résultats en faisant ça.

gravatar
Le Hollandais Volant a dit :

@Anon : justement, pour le JOIN j’aimerais beaucoup : mais comment je fais ?
J’ai essayé tout ce qui était immaginable hier, mais je vois pas comment récupérer la liste des commentaires correspondant à un article avec ça.

Notons que j’utilise le "fetchAll()" qui est assez grossier, plus pratique, mais groumand en ressources. Puisse-ce venir de là ?

gravatar
tester a dit :

@MutoKenji : ok autant pour moi mais ça m'étonne toujours l'indexation unique sur une date (il peut y avoir des doublons).

gravatar
Silversthem a dit :

@Le Hollandais Volant :
Si tu veux faire comme pluxml, il y a une fonction juste magique de php :glob()
tu fais genre ça : <?php $news = glob("articles/article-*.xml"); krsort($news); ?>
voilà, en 2 lignes tu as tes problèmes du résolus :p
et sinon, le xml c'est bof, vive le json \\o/

gravatar
MutoKenji a dit :

@tester : Tu as lu le lien que tu as posté ?
CREATE INDEX ne fait pas une indexation unique, juste une indexation.

gravatar
tester a dit :

@MutoKenji : oui oui :) Tu vois que mon lien sert malgé tout :)

Sinon j'utilise pas pdo mais comme ça peut-être :
foreach( $pdo->query("EXPLAIN SELECT * FROM commentaires WHERE bt_article_id=? AND bt_statut='1' ORDER BY bt_id, PDO::FETCH_ASSOC) as $row ) {
foreach($row as $k=>$v) {
echo "$k=$v | ";
}
echo "<br />\n";
}

gravatar
GoustiFruit a dit :

Les temps que tu as chronométrés correspondent au traitement complet de la page ou uniquement à la requête ?

Je viens de faire un petit test sur une BDD SQLite que je maintiens sur un pauvre processeur Atom N330, la BDD contient environ 740000 matchs de football et 14000 équipes, une requête du même genre que la tienne:
"SELECT * FROM Matchs WHERE Team1 = 1792 AND Score1 > 2 ORDER BY Score1" peut me sortir quelques dizaines de résultats en 0,010-0,015s. Bon il n'y a pas de champs texte dedans, ça doit certainement jouer un peu si les commentaires sont longs.

Enfin, ce qui est étonnant malgré tout, c'est la chute de l'utilisation des ressources lors de ton passage à MySQL ! C'est clair qu'il y a un goulot d'étranglement quelque part avec ta BDD SQLite...

gravatar
Le Hollandais Volant a dit :

@GoustiFruit : traitement complet oui. Mais je bosse activement là pour améliorer tout ça : utiliser des recherches précises plutôt que des comparaisons foireuses par exemple, lancement du moins de requêtes possibles…
Quelque chose aui aurait dû être fait depuis longtemps…

gravatar
MorganGeek a dit :

Non sérieux, y avait une telle fréquentation et pas d'index niveau DB ? J'ai du mal à le croire...
En tout cas... pauvre serveur \o/

gravatar
Guenhwyvar a dit :

Accessoirement, il me semble avoir lu je sais plus où que « SELECT * » était assez mauvais niveau performances, il vaut mieux lister les colonnes que l'on veut (quitte à toutes les mettre le cas échéant).

gravatar
MorganGeek a dit :

Je plussoie, le SELECT * est déconseillé

gravatar
Silversthem a dit :


L’affichage d’un seul article engendre la recherche dans l’intégralité des commentaires. Donc 10000 commentaires = 10000 parsage de fichiers. Aucun commentaire = aucun parsage de fichier.


Je ne sais pas comment tourne blogotext, mais mettre les commentaires d'un article dans le même fichier que cet article, avec un article par fichier, cela doit être suffisamment rapide pour toi timo ?

gravatar
Le Hollandais Volant a dit :

@Silversthem : dans ce cas la lenteur viendra quand on voudra lister l’ensemble de tous les commentaires, rechercher dans les commentaires seuls, trier les commentaires par auteur…

gravatar
Silversthem a dit :

@Le Hollandais Volant : ah, mais si tu utilisais quelque chose de plus rapide et léger que le xml, comme serialize ou json, normalement ça passe tranquille.
Toute façon xml n'est pas recommandé pour cet usage.

gravatar
Anon a dit :

@Le Hollandais Volant :

Je pense que ceci
SELECT * FROM commentaires WHERE bt_article_id=? AND bt_statut='1' ORDER BY bt_id

Peut se remplacer par cela :
Plutot que faire deux requetes, une pour l'article et une pour les commentaires, (si j'ai bien compris c'est comme ça que tu fais)
Tu fais juste une requete pour l'article en lui joignant ses commentaires associés :

SELECT * FROM articles LEFT JOIN commentaires on articles.article_id = commentaires.articles_id AND bt_statut='1' ORDER BY bt_id

Ca devrait marcher parfaitement.
Ensuite le fetchAll n'est pas indispensable, tu pourrais faire juste fetch(PDO::FETCH_ASSOC) ça devrait même te faire gagner quelques fractions de secondes...

Les jointures, le jour ou j'ai découvert ça, toute ma façon de coder a changé :p

gravatar
Julien et Nel a dit :

@Silversthem :

J'utilise serialize, mais il ne faut pas oublier d'ajouter une couche d'encodage comme base64.

Ceci permet d'éviter les bugs de cette fonction, mais ça alourdit légèrement les données.

gravatar
Le lapin masqué a dit :

C'est TOUJOURS comme ça. La "mode" du "no DBMS" revient, repart, revient, repart. Tout simplement parce que SQLite et compagnie, c'est très bien pour des "petites structures" (même si je concède que des améliorations sont faites à chaque nouvelle version pour supporter toujours plus de charge avec moins de ressources) mais dès qu'il faut passer à quelque chose de plus "gros", ça ne suffit pas.

Ça a TOUJOURS été comme ça. À un moment, il faut passer à un DBMS. Même si je pense que tu peux encore alléger la charge en faisant quelques optimisations comme proposé dans les commentaires plus haut, le passage à un DBMS est obligé.

Je suis content que cette théorie se vérifie encore une fois, mine de rien ^^

gravatar
Guenhwyvar a dit :

@Anon :


Les jointures, le jour ou j'ai découvert ça, toute ma façon de coder a changé :p


Perso j'arrive jamais à retenir les différences entre LEFT JOIN, RIGHT JOIN et INNER JOIN… Enfin, je les connais, mais je sais jamais qui est quoi.

gravatar
Le Hollandais Volant a dit :

@Anon : les jointures… je suis en train de découvrir ça depuis 3 jours^^.

@Julien et Nel : +1
@Silversthem : +1
J’utilise serialize dans la gestion des fichiers/images dans BT, c’est en effet très rapide.

@Le lapin masqué : +1
Je pense qu’il faut utiliser une techno pour ce à quoi elle est approriée et ne pas se voiler la face quand ça ne marche plus.

Quand j’avais BT 1.x, avec des fichiers textes, j’ai pu diviser le temps de chargement par 25, ce qui est colossal, mais au prix de manipulations peu pratiques (par exemple : inutile de parser le commentaires plus anciens que l’article auquel il est associé), mais à partir d’un moment ça n’est plus possible.

En revanche, pousser une techno à ses limites permet de voir là où ça coince et améliorer les choses, et ses connaissances.

gravatar
tester a dit :

@MutoKenji :
Pour revenir à la question : "Et sinon, cette histoire de nombre de commentaires avec un LIMIT, je suis pas sûr que ce soit une bonne pratique ?"

Perso je pense que si. Le seul truc c'est ça oblige à faire une requete supplémentaire sur la table article quand un commentaire est posté ou supprimé. Seulement en comparaison, il y beaucoup moins de commentaires postés/supprimés que d'articles+commentaires lus. Autrement dit quand tu alourdis d'une requete d'un côté, de l'autre (la lecture) tu économises en charge et temps de traitement...le ratio n'est pas le même.

ps : et la LIMIT tu peux aussi l'associer à une jointure. L'un n'empêche pas l'autre.

gravatar
Silversthem a dit :

@Julien et Nel : pas besoin de faire ça, suffit de compresser les données, j'ai jamais eu de problème avec, suffit d'appeler :
gzcompress
la seule différence avec l'autre, c'est :



Ce n'est pas la même chose que la compression gzip, qui inclut quelques en-têtes de données. Voir gzencode() pour la compression gzip.


la doc de php sur gzcompress

gravatar
Le Hollandais Volant a dit :

@Guenhwyvar : http://www.codeproject.com/KB/database/Visual_SQL_Joins/Visual_SQL_JOINS_V2.png
Ce schéma permet de comprendre un peu.
Le LEFT et le RIGHT représentent les tables que tu écris en premier dans ta requête ou après.

Ici :
SELECT * FROM articles LEFT JOIN commentaires on articles.article_id = commentaires.articles_id AND bt_statut='1' ORDER BY bt_id

Article est à gauche de commentaires, donc LEFT JOIN devrait sélectionner tous les articles, même ceux qui n’ont pas de commentaires.

Un RIGHT JOIN aurait sélectionné seulement les articles ayant des commentaires, en plus de compter les commentaires orphelins (en cas de suppression d’un article par exemple).

gravatar
Silversthem a dit :

@Le lapin masqué : je ne suis pas d'accord, si tu utilise correctement les fonctions natives de php, (glob() et compagnie...) cela va plus vite que si tu passe par un programme externe (mysql ou autres) ; sqlite semblait être un bon compromis entre les deux, mais finalement, c'est un peu le mix des défauts des 2 techniques, ça à tout les problèmes de mysql et tout ceux des fichiers.

C'est une méthode différente de programmer, avec les fichiers, tu enregistre et tu lis, donc aucun problème de logique ; tandis qu'avec un SGBD, tu utilise des requêtes, c'est tout de suite moins logique, avec des fichiers, tu peux pas te planter de méthode, alors qu'avec un SGBD, y a toujours un mec qui va t'expliqué que CECI c'est mieux que CELA parce que blablabla...

Après c'est un avis perso, si tu préfère taper 10 lignes pour avoir le même résultat qu'avec 2, cela ne me dérange pas.
(et puis tu peux dire SGBD comme tout le monde :p )

gravatar
Le Hollandais Volant a dit :

Bon, c’est pas MySQL qui est en cause visiblement (j’aurais dû commencer par là je pense).

Le recherche des commentaires associés à un article prend 2 millisecondes. Le rendu de la page est de 300 millisecondes… Il y a un autre problème quelque part.

Au passage, prenant en compte juste les fonctions SQL, avec cet exemple, SQLite est plus rapide que MySQL (2,3 millisecondes en moyenne pour SQLite contre 4,2 millisecondes pour MySQL). Les temps d’accès à SQLite sont également beaucoup plus stables (faible fluctuations).

gravatar
Silversthem a dit :


Le recherche des commentaires associés à un article prend 2 millisecondes. Le rendu de la page est de 300 millisecondes… Il y a un autre problème quelque part.


o_O
Oui, vérifie les autres trucs sur ta page, le calendrier par exemple, parce que 298 ms, c'est pas mal quand même.


Au passage, prenant en compte juste les fonctions SQL, avec cet exemple, SQLite est plus rapide que MySQL (2,3 millisecondes en moyenne pour SQLite contre 4,2 millisecondes pour MySQL). Les temps d’accès à SQLite sont également beaucoup plus stables (faible fluctuations).


:/ mais sqlite est plus rapide qu'un bon vieux système de fichiers ? (parce après tout sqlite c'est quand même un fichier à la base)

gravatar
Le Hollandais Volant a dit :

@Silversthem :


/ mais sqlite est plus rapide qu'un bon vieux système de fichiers ?


Pour de la simple recherche, non je ne pense pas (cf Shaarli). Mais pour faire des recherches entre les différents champs c’est à mon avis plus simple.

Faut que j’essaye.

gravatar
Julien et Nel a dit :

@Silversthem :

Sqlite a été conçu pour garder la facilité d'installation comme les fichiers textes et avoir une vrai base de donnée comme mysql. Après, le mieux reste au niveau des performances MYSQL, je pense. Si on veut une facilité absolu, les fichiers textes seront le mieux. Si on veut combiné performance et facilité, on utilisera SQLITE. Ceci dépend de ce qu'on veut et à quel public s'adresse le script qu'on distribue. Il est à savoir que sqlite est limité au niveau de son poids ou taille.

gravatar
Guenhwyvar a dit :

@Le Hollandais Volant : Bah après ça dépend si le service externe est important ou pas… Disqus gère complètement les commentaires, donc le jour où ça pète, y'a plus rien. Mauvaise idée. Quelque chose comme Gravatar, par contre, apporte quelques fioritures, mais n'est pas essentiel. C'est bien quand c'est là, mais c'est pas perturbant quand ça manque.

gravatar
tester a dit :

@Le Hollandais Volant : ouai mais ça (l'exemple de cloudflare), ça se contourne en ajoutant un dns secondaire chez ton registrar. Si cloudflare tombe, le dns secondaire prend le relai...enfin normalement.

gravatar
Fred a dit :

@Le Hollandais Volant : On est tout à fait d'accord là dessus : les optimisations ne peuvent jamais satisfaire tous les cas d'usage, sinon ça serait trop beau. Mais justement, étant donné l'inutilité apparente de "rechercher dans les commentaires seuls ou trier les commentaires par auteur", ne peut on pas simplement mettre ces cas de figures là à la poubelle pour optimiser le principal : récupérer tous les commentaires associés à un article donné ?

Est-ce que ces fonctionnalités sont utiles / indispensables à BlogoText ou énonce tu simplement des cas fictifs qui deviendraient inefficaces en ayant une organisation des fichiers telle que Silversthem la décrit ?

gravatar
Silversthem a dit :

@Fred : +1, de toute façon si tu veux trier les commentaires par auteurs, c'est comme pour l'import/export en xml, ça prend beaucoup de temps, mais tu ne le fais pas souvent.

gravatar
Sbgodin a dit :

@Le Hollandais Volant : je viens de réaliser mes benchmarks. Ça coince au niveau des templates et des commentaires. Le code passe de multiples fois dans des sous routines pour afficher les commentaires, y compris sur la page d'accueil.

Chez moi en local, Firebug me donne 3.44 secondes pour charger la page d'accueil. Sachant qu'en local j'ai une réplique de mon petit blog totalisant 12 commentaires.

Je travaille sur Mercurial, et j'ai fait les mesures. Le code source de la version Benchmark, utilisant la dernière version de Blogotext, est ici :

https://sekur.sbgodin.fr/hg/blogotext/archive/562a3a66ce39.zip

gravatar
Le Hollandais Volant a dit :

@Sbgodin : je suis moi aussi en train de passer l'ensemble du code au "microtime()".

Avec ce que j'ai fait là, j'ai déjà reduit la durré de chargement de 25%. Un bon début.

gravatar
tester a dit :

On va être obligé de faire un diff sur le code source ou t'envisages de donner des détails par la suite (perso ça m'intéresse...) ?

gravatar
Julien et Nel a dit :

@Sbgodin :

Je suis actuellement sur windows, existe t-il un logiciel graphique pour utiliser bitbucket comme github ?

gravatar
Sbgodin a dit :

@Julien et Nel : TortoiseHg. De la bombe. Ça marche aussi bien sous Linux que sous Windows. Ils ont le même style d'outil pour Subversion. Que du bon.

http://tortoisehg.bitbucket.org/download/index.html

Une précision. J'ai divergé le projet de Timo, en incorporant tous ses travaux et en publiant les miens. Mais la seule version officielle reste celle publiée sur son site.

gravatar
Sbgodin a dit :

@Julien et Nel : Mmhh... Ça a l'air mal parti ton truc. Bitbucket fournit du Git et du Mercurial. Dans le blog, il est question de Git. Or, j'ai utilisé Mercurial.

gravatar
Sbgodin a dit :

Mercurial et Git sont deux gestionnaires de code source décentralisés. On peut faire la même chose avec les deux, mais les philosophies sont différentes. Mercurial a pour lui la simplicité d'abord, Git l'efficacité d'abord.

Exemple typique : l'annulation des changements dans le répertoire contenant les sources.

Dans Mercurial, on dit ce qu'on va faire. On va revert-er les modifications du fichier. C'est une approche métier.
hg revert fichier
Dans Git, on dit ce que ça va faire. On va réinitaliser la staging area, la working tree et déplacer le pointeur HEAD vers la révision parente.
git reset --hard
Parce que, oui, on peut annuler de pleins de façons différentes. Et donc, bien étudier les trois notions que j'ai données qui sont propres à Git. Après, vous savez pleins de choses ;-)

gravatar
Le Hollandais Volant a dit :

Quelques nouvelles :
— effectivement, la gestion des templates prenait beaucoup de temps.
– en cause : l’encart des derniers commentaires (oui,oui, ce sont les commentaires qui sont l-e-n-t-s).
– l’encart des commentaires était généré environ 3 fois (gros WTF oui).


J’ai ré-écrit une partie de la gestion des templates (code qui n’a jamais été retouché depuis… le début je crois bien), et je passe de 0,24s à 0,08s.
C’est déjà beaucoup mieux.

En revanche, sur ces 80 ms, 45 ms sont bouffées par une requête SQL qui fait un SELECT de 5 commentaires. Dingue non ?
La requête est pourtant simple :


SELECT bt_author, bt_id, bt_article_id, bt_content FROM commentaires WHERE bt_statut ='1' ORDER BY bt_id DESC LIMIT 0, 5



Et ce qui est totalement délirant, c’est que si je met ça :


SELECT bt_author, bt_id, bt_article_id, bt_content FROM commentaires WHERE bt_statut ='1' LIMIT 0, 5



Alors la requête se fait en TRÈS peu de temps (mais retourne des commentaires que je ne veux pas) : sans le ORDER BY, je passe à une page générée en 30 millisecondes.

gravatar
Sbgodin a dit :

@Le Hollandais Volant : Faute de jeu d'essai pour comparer, je ne peux que conjecturer. Les opérations sont comme suit :
* (F) On filtre les articles en ligne (pas les invisibles).
* (T) On trie par date (utiliser l'id est une mauvaise idée, l'id n'est pas forcément croissant).
* (L) On se limite aux cinq derniers.

L'opération (L) ne peut se faire avant le filtrage, sinon on aurait que 5 éléments pris au bonheur de la chance. Elle ne peut non plus se faire avant (T), pour les mêmes raisons. Par contre, (F) et (T) sont interchangeables.

La limitation (L) n'optimise que les données transmises, pas le reste de la requête puisque ça se fait en dernier. Le tri (T) est probablement fait après le filtrage. J'en déduis que la totalité des données récupérées (filtrées donc) est en mémoire avant d'être triée. C'est ce qui doit prendre du temps.

Idée de solution : placer un index sur bt_statut voire sur bt_statut ET bt_id.

gravatar
Anon a dit :

@Le Hollandais Volant :
O_o curieux...

Si c'est pas un problème d'index, récupère tout sans Order by et fais le tri en php ça devrait pas être la même.




Bon, maintenant la question troll du jour :

Blogotext ou Shaarli ?

gravatar
Silversthem a dit :

@Anon : blogotext intègre shaarli ou un truc équivalent.

Pour le tri en php +1 j'ai eu la même idée

gravatar
Le Hollandais Volant a dit :

@Silversthem : ok pour le trie en PHP, mais il restera un problème non resolu au niveau de SQL: c'est pas normal qu'il fasse ça, si ?

@Sbgodin :

J'ai déjà un index sur Bt_id ET bt_article_id. Je veux bien indexer chaque colonne mais ça ne servirait plus à rien du tout.

gravatar
jleens a dit :

@Le

@Le Hollandais Volant :

As-tu aussi mis un index sur bt_id ?

Car tu dis avoir fait cela:
CREATE INDEX art_id ON commentaires ( bt_article_id );
CREATE INDEX bt_date ON articles ( bt_date );

Mais l'order by se fait sur bt_id, je pense qu'il faudrait aussi mettre un index sur cette colonne.

gravatar
jleens a dit :

@Le Hollandais Volant :

Sorry, ton dernier commentaire n'était pas encore publié quand j'ai commencé le mien.

Je suis d'accord avec sbgodin, j'ai déjà constaté sur un autre SGBD que la création d'un seul index sur la colonne sur laquelle se porte la clause where et sur celle sur la quelle se porte le order by améliorait grandement les choses. Donc ici un index portant à la fois sur bt_statut et sur bt_id.

gravatar
jefaispeuralafoule a dit :

Concernant les jointures.
Selon la BDD employée, certaines syntaxes sont plus performantes que d'autres. Typiquement
Select * from A where A.c1= B.c1
Revient au même que
select * from A inner join B on A.c1= B.c1
Or la seconde est plus performante sur les BDD comme SQL Server. (je n'ai pas toutes les BDD et leurs points forts/faibles en tête).
pour les jointures donc, c'est la gestion des ensembles. Il y a pas mal de docs intéressants sur le net, et cela nécessite de bien pratiquer pour tout saisir. Ceci étant, de bonnes jointures bien pratiquées améliorent notablement les performances. Cependant, sqlLite est il handicapé par ces jointures, ou bien plus par le fait que de parser des fichiers en masse (txt) est plus lourd? Vu les stats, j'aurais tendance à soupçonner la surcharge du parse, ou des indexs à revoir.

gravatar
Le lapin masqué a dit :

@Silversthem : Ça va au delà de ça, c'est un vrai problème structurel, d'infrastructure au final. Si tu lis un fichier, tu n'auras pas les mêmes performances sur un SSD et sur un mécanique 5400 tpm.

Comme le dit TiMo, il faut tester et utiliser pour voir les limites et comprendre ; du moins au début, quand on n'a pas/peu d'expérience. Ensuite l'utilisation d'un DBMS (j'ai toujours dit/écrit DBMS, je vais pas changer maintenant hein) apporte d'autres contraintes, et souvent l'intervention d'un DBA pour pouvoir en tirer pleinement profit.

SQLite et compagnie, c'est bien pour commencer un projet, ne pas se prendre la tête. Mais il faut bien faire gaffe à bien foutre une couche d'abstraction, car le jour où tu dois switcher sur un DBMS classique (et il arrive souvent, ce jour), bah t'es mal barré si tu n'y as pas pensé avant.

Quant au fait de juger la qualité/rapidité d'un code à son nombre de lignes/caractères... Je suppose que tu veux plaisanter, hein ? Quelques exemples rapides : "strpos($haystack, $needle) !== false" est 10 fois plus rapide que "ereg($needle, $haystack)" ; "str_replace($search, $replace, $subject)" plus rapide que "strtr($subject, $array)" ; "preg_replace('/^,+/', "", preg_replace('/,+$/', "", …))" beauuuuucoup plus rapide que "preg_replace('/^,*|,*$/m', "", $string)" (là je triche, trim() est encore meilleur, OK) ; "explode(",", $string)" environ 5 fois plus rapide que "split(",", $string)" (tu peux benchmarker ça sur ton propre serveur, tu obtiendras environ les mêmes écarts) ; enfin bref.... la qualité d'un code ne s'estime plus au nombre de ses lignes/caractères. COCOMO, c'est terminé.

Donc, oui, je préfère écrire 10 lignes à la place de 2. Déjà parce que dans un premier temps ça me permet de bien comprendre ce que je fais. Ensuite parce que "early optimization is the root of all evil". Enfin parce que 10 lignes sont parfois plus efficaces que 2 : un processeur n'est pas un cerveau humain. :)

gravatar
tester a dit :

au pifomètre, est-ce que t'as essayé de placer la limit avant le order by ? Peut-être que sql traite les paramètres les uns après les autres (sous-entendu que le tri se fait sur toute la table avant d'appliquer la limit) ?

gravatar
Silversthem a dit :

@Le lapin masqué : euh, lol ?
Avec des fichiers, tu fais simplement et rapidement, et ça marche, des tests ont été fait sur le site du zéro, même avec 500 news, les fichiers son bien plus rapide qu'un DBMS, et cela ne me surprend pas le moins du monde. Une Db c'est bien beau mais qu'on peut l'éviter, faut pas hésiter.

gravatar
Julien et Nel a dit :

@Silversthem :

Je ne sais pas où tu as vu les test là, mais une base de donnée sera toujours plus rapide que des fichiers textes. J'utilise les fichiers textes pour le coté facile à installer, mais MYSQL sera toujours plus rapide que SQLITE ou les fichiers textes.

gravatar
tester a dit :

@Silversthem : Pauvre de moi, j'avais zappé ta réponse...bref pas bonne l'idée de la limit avant le tri.

gravatar
tester a dit :

EDIT : @Sbgodin :

C'est chiant qu'on ne puisse pas éditer quand même...et puis on ne peut pas s'inscrire je crois ?

gravatar
Silversthem a dit :

@Julien et Nel : à la base, les bases de donnés sont des fichiers, pas forcément texte, mais des fichiers classiques, et faut pas croire ce qu'on te dis, fais des tests, tu verra ;)

gravatar
jefaispeuralafoule a dit :

Heuuu la différence entre une structure "texte" et data, c'est la manière dont les données sont agencées. Après, l'accent peut être mis sur la performance d'indexation, de structuration, et de compactage de la donnée. De ce fait, oui les fichiers de BDD contiennent de la donnée (lapalissade...) mais l'organisation de celle-ci fait toute la différence.

gravatar
Le Hollandais Volant a dit :

@jefaispeuralafoule : oui, dans un SGBD comme SQLite ou MySQL, les données sont bien quelque part sur le disque, dans des fichiers.

Si on utilise des fichiers XML comme PluXML ou Blogotext V1, alors il y a des également des spécificités.
Par exemple, blogo utilisait un système de rangement par date :
dossier articles -> dossier année -> dossier mois -> id-article1.txt, id-article2.txt


Si on voulait sortir tous les articles de 2012/12, c’était extrêment rapide : on a tout de suite le dossier à trier.
Idem pour les commentaires.

Les commentaires étant rangés par date, les trier par article était long. C’était vraiment pas pratique et de là la lenteur de BT version texte quand le nombre de commentaires était important.

Le XML et une mauvaise idée car le parsage et la recherche dans les balise est aussi trèèèès lente et consommatrice en ressource (surtout avec des preg_match() : faut mieux utiliser 12 fois strpos()).

Si je devais faire maintenant un CMS full-text, j’utiliserais serialise avec une DB pour les articles, et un DB pour chaque article contenant les commentaires et enfin un index contenant la liste des commentaires trié par date et avec leur chemin. Cette dernière était uniquement utilisée lors de la recherche de commentaires hors du contexte de rangement par article (encart des derniers commentaires, par exemple).

Là ça serait comme ré-écrire la roue "mysql", vu qu’on va beaucoup plus loin qu’un simple stockage d’articles dans un fichier.

gravatar
Le lapin masqué a dit :

@Julien et Nel : Alors, je dirais pas "toujours".

De toute manière, une des bonnes manières de faire est de se fonder sur un modèle MVC de manière à séparer la nature de ta base de données du reste de ta programmation. Ensuite, tu fais les tests que tu veux, ça fait aussi partie du boulot d'analyste.

Quand tu as 2 "tables", tu peux faire des fichiers, ou du SQLite, ça passera très bien, même plus rapide qu'un DBMS je suppose, vu que les quantités et complexités traitées ne sont pas dans le domaine adressé par un DBMS classique.

Pour une application ou un environnement plus complexe, où tu dois traiter des dizaines de tables, voire des centaines quand ta DB respecte les formes normales les plus élevées, avec des contraintes d'intégrité calculées, etc. sans même parler d'environnement réparti, c'est juste du domaine de l'impossible en technologie "No DBMS".

Donc encore une fois, le SQLite, c'est très bien pour commencer un projet, pour pas se prendre la tête, pour un niveau de complexité assez bas (allez, non, soyons honnêtes, avec les dernières versions de SQLite on peut se permettre une complexité moyenne), pour un volume de données limité ou pour une durée limitée. Il est d'ailleurs, à mon sens, contre-productif de partir directement sur un DBMS quand on commence un projet qu'on fera évoluer "au fur et à mesure de l'eau".

Les "No DBMS" et les DBMS classiques ont chacun trouvé leurs champs et domaines d'application, et ils sont, pour moi en tout cas, clairement définis.

L'important, au final, est de bien avoir conscience que la programmation d'une fonctionnalité ne doit PAS dépendre de la technologie de la base de données. Et quand on ne sait pas trop où on va (et c'est "mal" hein, soit dit en passant :p), SQLite et compagnie sont de très bons moyens de se concentrer sur autre chose. Mais là où il y a moins de contraintes, il y a aussi plus de limites. Un DBMS permet de s'affranchir de ces limites, mais à condition d'en accepter les contraintes.

Au final, il n'y a pas UNE méthode d'optimisation, c'est pour chaque application différente. Il n'y a que des grandes lignes et c'est, au final, l'expérience qui fait toute la différence.

Commencez vos projets avec SQLite, parce que c'est certainement le meilleur moyen de commencer, mais ne vous obstinez pas dans cette/une technologie lorsque vous atteignez les limites. À partir d'un moment, il est moins coûteux de passer à un DBMS que de chercher une optimisation sur SQLite et compagnie. C'est du pragmatisme. On peut refuser le pragmatisme hein, c'est un choix, que chaque programmeur/chef de projet/chef de produit fait en son âme et conscience.

gravatar
GoustiFruit a dit :

@Le Hollandais Volant : A quoi correspond la colonne "bt_id" sur laquelle tu veux trier par ordre décroissant, c'est l'identifiant de chaque commentaire ?Pourquoi aussi avoir un "LIMIT 0, 5", tu fais de la pagination ? Un "LIMIT 5" devrait suffire (mais ne devrait pas changer grand chose).

gravatar
Silversthem a dit :

@Le Hollandais Volant : hmm, il y a tellement plus simple, tu serialize() directement des objets, comme ça, tu fais :

$articles = unserialize(file_get_contents('ficherdesarticle.txt'));



Le XML et une mauvaise idée car le parsage et la recherche dans les balise est aussi trèèèès lente et consommatrice en ressource (surtout avec des preg_match() : faut mieux utiliser 12 fois strpos()).



DomDocument est ton ami

Si jamais tu veux repasser en texte voilà comment je ferai :
*tu sauvegarde chaque article dans un fichier, et ces commentaires dans ce même fichier, via un tableau avec serialize ou json
*tu récupère un tableau contenant la liste des fichiers via glob()
*tu récupère les X derniers articles grâce à array_splice et krsort()
*tu les affiches

Séparer les articles des commentaires est selon moi une mauvaise idée, je ne pense pas que tu ai vraiment besoin de trier les commentaires par auteur.
L'avantage premier de ma méthode est que tu n'a qu'un seul fichier à ouvrir.

(si tu veux garder tes dossiers par date, sache que glob fait ça très bien).

Tu peux même faire un fichier texte (brut) qui contient juste le nom du fichier, comme ça tu l'ouvre, tu prend les 5 dernières lignes, tu ouvres ces fichiers, et voilà ^^.

Suffisait d'un petit réfléchir, et puis, bt n'a pas besoin de mysql :)

PS : je te conseille de bosser avec des tableaux, php propose des tas de fonctions super cool, j'ai presque l'impression qu'il a été codé spécialement pour l'utilisation de tableaux.

PS[2] : tu peux aussi passer ton code en POO, grâce aux interfaces, tu peux transformer tes objets en tableaux (faire des foreach dessus, toussa,toussa), je crois même que DomDocument utilise ce principe.

PS[3] : je te conseille json

PS[4] : DomDocument ça roxx ! ça lit les xml à la manière de javascript (presques les mêmes méthodes)

gravatar
sebsauvage a dit :

Que ce soit une base de données ou des fichiers, au final tout est stocké dans des fichiers. A la différence près:
- qu'avec les fichier vous vous reposez sur deux indexations: celle du système de fichiers et la vôtre (format interne des fichiers), ce qui peut (ou non, selon les cas), être plus performant qu'une base de données.
- avec la base de données vous disposez de fonctions de selection/jointure toutes prêtes (et souvent très optimisées par des années d'effort). En cas de fichiers vous devez implémenter ça vous-même.
- dans les deux cas, les données du disque atterrissent toujours dans un cache (celui de l'OS pour les fichiers, celui de la db pour la db.).
- la base de données vous offres des outils supplémentaires (transaction, gestion des droits, des accès concurrents...). Encore une fois, avec des fichiers c'est à vous de ré-implémenter ça (ce qui n'est pas forcément léger).

Au niveau des performances (excellente réponse du Lapin Masqué), cela va dépendre de vos cas d'utilisation. Ce n'est pas pour rien que des proxy comme Squid-cache utilisent un stockage sous forme de fichiers: c'est bien plus performant.

SQLite est effectivement mi-chemin entre un stockage sous forme de fichiers et une base de données. (Note: j'ai utilisé SQLite pour des bases de 2 Go sans problème (mais ce n'était pas pour un site web, mais pour du data-mining)).

Perso, pour Shaarli et ZeroBin j'ai utilisé un stockage sous forme de fichiers, mais cela ne marche que parce que ce sont des cas bien d'utilisation bien spécifiques:

- Pour Shaarli, il n'y a pas d'accès concurrents en écriture: Je peux donc faire fi de la gestion des accès concurrents: Pas besoin de base de données. Le stockage sous forme de fichiers marche bien. Il n'y a qu'un fichier de données lu dans 99% des cas: il est déjà dans le cache de l'OS. Très peu d'I/O disque donc, bonnes performances (à part un ungzip, mais c'est très rapide)).

- Pour ZeroBin, c'est le contraire: Un grand nombre d'accès concurrents. Le stockage sous forme de sous-répertoires à deux niveaux fonctionne: En limitant le nombre de fichiers par répertoires à 256, on limite la taille des indexes de fichiers de l'OS et on garde d'excellentes performances. Ce cas fonctionne uniquement parce qu'on a pas besoin de faire de recherches dans l'ensemble des données (C'est quasiment un accès clé-valeur).


Donc, selon les cas, choisissez:
- le stockage sous forme de fichiers
- une base SQLite
- une vraie base de données relationnelle
- une base clé-valeur.

Le chois se fera sur divers critères:
- besoin ACID
- besoin de contraintes sur les données (clé étrangères, liste de valeurs, not null...)
- besoins de calculs relationnels (jointures, etc.)
- besoins de recherche (recherche texte, clés)
- volume des données.
- accès concurrents ou non.
- hébergement par des tiers (typiquement le cas des bases clé-valeur dans le "cloud").
- possibilités de parallélisation.
- temps de réponse exigés.
- etc.

Donc il faut bien faire attention à ses choix, mais en aucun cas de rejeter le stockage sous forme de fichiers ou une base SQLite.


Si vous voulez stocker sous forme de fichier, le truc pour ne pas perdre en performance, c'est de limiter le nombre de fichiers par répertoire: Les indexes de fichiers des OS sont généralement peu performants, et en mettant beaucoup de fichiers, ça sera lent.
Essayez d'avoir moins de 256 fichiers dans un répertoire. Besoin de découper (genre stockage clé-valeur ?), il existe différentes méthodes:
- date (comme dans l'ancien blogotext): 2013/02/04/...
- hash (comme dans ZeroBin): hashez la clé (ce qui assure une répartition pseudo-aléatoire et homogène) et utilisez les octets comme sous-répertoire: 0a/fc/3b/...


Il y aurait encore beaucoup de choses à dire.  :-)

gravatar
Le lapin masqué a dit :

"excellente réponse du Lapin Masqué"

Je vais pas m'en remettre je crois... J'ai chaud d'un coup là, j'sais pas pourquoi.... ^^

gravatar
tester a dit :

@Silversthem : T'as pas lu la dernière phrase ? Non non tout n'est pas dis :p
Juste à titre d'exemple on peut aussi rappeler que le choix du system de fichiers selon qu'il soit en ext3, xfs, ntfs, etc joue un rôle prépondérant sur les performances etc etc...et puis bon, sorti de la conception du programme il y a ensuite toute la partie cache à explorer...

Bref pour paraphraser : il y aurait encore beaucoup de choses à dire. :-)

gravatar
Le Hollandais Volant a dit :

@GoustiFruit : bt_id c’est la date au format YYYYMMDDHHIISS.
L’id est aussi ce qui le rend unique, il joue les deux rôles.

Est-ce parce que ce champ fait 14 caractères de long (LONGING) que ça rame tant ? Là aussi je vais faire un tas de bench avec de grosses BDD ce soir (genre 10000 entrées contenant du lorem-ipsum).

Le LIMIT 5 c’est parce que c’est uniquement pour l’encart des derniers commentaires (que tu vois sur mon site, dans la colonne de droite là) : je ne veux afficher que les XX derniers commentaires.

gravatar
Silversthem a dit :

@tester : certes, mais là ça part en hors sujet.
faut dire que sebsauvage a bien résumé l'histoire.
Concernant les SGBD, moi j'ai toujours vu ça comme le successeur du tableur, un grand tableaux avec pleins de données dedans, c'est parfait pour stocker une liste de membres ou les messages dans un forum, mais pour un moteur de blog comme blogotext, les fichiers ça reste le top du top.

Timo, si jamais tu repasse aux fichiers pour bt (ce que je te souhaite ;) ), utilise plus le xml, prend plutôt un truc génial comme json ou serialize.

PS : (je crois que cet article est celui qui a le plus de commentaire)

PS[2] : @Le lapin masqué : t'as trop de chance #jalousie

gravatar
GoustiFruit a dit :

@Le Hollandais Volant : A voilà qui est intéressant ! En effet si tu tries sur une chaîne alphanumérique (même s'il n'y a que des chiffres dans ton cas), ça risque de bien ralentir... Les formats de dates "natifs" sous SQLite sont dispo ici: http://www.sqlite.org/lang_datefunc.html (voir paragraphe Time Strings), dans ton cas il aurait fallu utiliser quelque chose comme ça: "YYYY-MM-DD HH:MM:SS".
Mais je te propose d'essayer ceci: dans SQLite toutes les tables ont par défaut une colonne "ROWID" qui est auto-incrémentée. Même si tu n'utilises pas de colonne auto-incrémentée, et même si tu ne la vois pas, tu dois avoir une telle colonne dans chaque table ! Et comme sa valeur auto-incrémentée, ça veut dire que les derniers commentaires auront forcément les ROWID les plus élevés ! Donc change ta requête comme ça:
SELECT bt_author, bt_id, bt_article_id, bt_content FROM commentaires WHERE bt_statut ='1' ORDER BY ROWID DESC LIMIT 5

PS: "LIMIT 5" au lieu de "LIMIT 0, 5"

gravatar
Le Hollandais Volant a dit :

@Silversthem : nope, il y a deux articles plus commentés ;)
Celui où je dénonce les moteurs d’énergie libre et celui sur les autoblogs :
http://lehollandaisvolant.net/?d=2012/08/27/16/53/13-le-moteur-a-production-denergie-sur-numeraire (118 comms)
http://lehollandaisvolant.net/?d=2011/07/12/23/20/29-autoblog-une-arme-contre-la-censure (185 comms)

@GoustiFruit : les formats de date j’ai voulu éviter depuis le début à cause du bordel entre les différents SGDB (actuellement mon système switch entre MySQL et SQLite avec un code SQL à 99% identique).

C’est pas possible de rester sur du YMDHIS pour le champ de date ? Faut obligatoire qu’il y ait un séparateur ?


Et comme sa valeur auto-incrémentée, ça veut dire que les derniers commentaires auront forcément les ROWID les plus élevés 


FAUX !!1

Si j’utilise l’import-export XML, de vieux commentaires seront au dessus de nouveaux.

gravatar
sebsauvage a dit :

Sebsauvage aime que vous appréciez sa remarquable personnalité, les louanges, ses outils dont il adore rappeler au cours d'une démonstration qu'ils existents, son site aussi "moulé à la louche depuis 1999", et bien évidemment sa marque Sebsauvage.

Pour toutes ces raisons, Sebsauvage vous remercie le plus chaleureusement du monde.

PS : bientôt des tee shirts à l'effigie de mon avatar. ;-)

gravatar
Le Hollandais Volant a dit :

@sebsauvage : t’es sûr que le sebsauvage.com n’est pas à toi là d’un coup :D ?

Pour le tshirt, je prendrais plutôt une casquette avec le troll/monstre/créature de ta page rhaa© :p

gravatar
Sbgodin a dit :

@tester : J'explique sur le projet comment je gère les développements. En particulier, j'y explique la stratégie de développement.

En résumé, tu peux soit envoyer des patchs (à partir de timo-base), soit faire des pull requests, soit diverger (fork) le projet. Les trois méthodes sont cumulatives.

gravatar
tester a dit :

@Sbgodin : ça devient chaud le topic là :)

Oki, je te suis sbgodin.

gravatar
GoustiFruit a dit :

@Le Hollandais Volant : Concernant les dates, si tu utilises une chaîne de caractères avec un format perso, SQLite ne peut pas savoir comment trier, dans ton cas il doit faire un tri alphanumérique en comparant toutes les chaînes les unes avec les autres. Je pense que quand le format utilisé est natif, il y a une conversion simple des dates en valeurs numériques qui sont bien plus rapides à comparer.
Concernant ma suggestion, je ne sais pas comment fonctionne l'import/export mais SI, ROWID étant autoincremente, les derniers commentaires auront les ROWID les plus élevés ! Même si tu supprimes des commentaires, les vieux ROWID ne seront plus utilisés. Le seul cas où ça pourrait éventuellement poser problème, ce serait si tu autorisais la modification des commentaires.

PS: Les ROWID sont utilisés en interne dans SQLite, à mon avis ils ne passent pas à l'exportation.
PS2: Il est très facile de modifier le format des dates en batch une fois le fichier d'exportation créé avec un simple éditeur de texte.

gravatar
Le Hollandais Volant a dit :

@GoustiFruit : j’ai fait quelques bench : une base SQLite de 300'000 entrées :
CREATE TABLE IF NOT EXISTS data ( ID INTEGER PRIMARY KEY, date BIGINT, content LONGTEXT, statut INTEGER );
⚫ date : date('Ymd').rand(10,23).rand(10,59).rand(10,59). Donc comme dans blogo : (20130225123053 par exemple)
⚫ content : md5($rand).sha1($rand) $rand = mt_rand().rand(0,10).rand(10, 20); (donc du texte)
⚫ statut : rand(0,1)

Les tests : deux séries de tests, une avec ça au moment de la création :
CREATE INDEX date ON data(date);
Les durées prennent en compte :

⚫ le temps d’ouverture de la base (new PDO(blabla))
⚫ l’accès à la base (la requête à proprement parler)
⚫ un fetch() qui boucle sur toutes les lignes (avec while)

Sélection simple d’une colonne sur toute les lignes :
➤ 0,48 s : "SELECT content FROM data" (avec index)
➤ 0,62 s : "SELECT date FROM data" (avec index)
➤ 0,56 s : "SELECT statut FROM data" (avec index)
➤ 0,48 s : "SELECT ID FROM data" (avec index)

➤ 0,48 s : "SELECT content FROM data" (sans index)
➤ 0,61 s : "SELECT date FROM data" (sans index)
➤ 0,56 s : "SELECT statut FROM data" (sans index)
➤ 0,48 s : "SELECT ID FROM data" (sans index)

Jusque là, on remarque qu’il n’y a aucune différence. Étrangement la sélection du champ "date" est jusqu’à 20% plus lente que toutes les autres. Allez savoir pourquoi… (je rappelle que pour SQLite, que l’on utilise "INT", "BIGINT" ou "TINYINT", ça reste une simple "INT" (rtfm)

Second test : une sélection générale avec tri sur un champ :
➤ 2,21 s : "SELECT * FROM data ORDER BY content" (avec index)
➤ 1,57 s : "SELECT * FROM data ORDER BY date" (avec index)
➤ 1,68 s : "SELECT * FROM data ORDER BY statut" (avec index)
➤ 1,15 s : "SELECT * FROM data ORDER BY ID" (avec index)

➤ 2,22 s : "SELECT * FROM data ORDER BY content" (sans index)
➤ 2,15 s : "SELECT * FROM data ORDER BY date" (sans index)
➤ 1,70 s : "SELECT * FROM data ORDER BY statut" (sans index)
➤ 1,15 s : "SELECT * FROM data ORDER BY ID" (sans index)

Encore une fois, le temps d’accès est long. On note cependant que lors du tri sur le champ "date", il est 25% plus rapide avec l’index.

Troisième test : une sélection générale, avec un tri sur une colonne et avec une limite du nombre d’entrées à 100 retours.
➤ 0,94 s  : "SELECT * FROM data ORDER BY content LIMIT 100" (avec index)
➤ 0,003 s : "SELECT * FROM data ORDER BY date LIMIT 100" (avec index)
➤ 0,54 s  : "SELECT * FROM data ORDER BY statut LIMIT 100" (avec index)
➤ 0,002 s : "SELECT * FROM data ORDER BY ID LIMIT 100" (avec index)

➤ 0,76 s  : "SELECT * FROM data ORDER BY content LIMIT 100" (sans index)
➤ 0,54 s  : "SELECT * FROM data ORDER BY date LIMIT 100" (sans index)
➤ 0,54 s  : "SELECT * FROM data ORDER BY statut LIMIT 100" (sans index)
➤ 0,0014 s : "SELECT * FROM data ORDER BY ID LIMIT 100" (sans index)

Bim ! Là la présence de l’index change absolument tout.
3 millisecondes au lieu de 500 millisecondes. Donc l’index sert à quelques chose après tout. Étrangement dans blogotext, la différence est totalement inexistante..

gravatar
sebsauvage a dit :

Juste pour dire que le commentaire 108 c'est pas moi. (Timo, t'as accès aux IP :-)

(Tester, je présume que c'est toi. T'aimes bien me troller, hein ?)

Ma réponse, c'était pas pour faire ma promo (je m'en fous), c'était pour montrer que des solutions alternatives fonctionnent.

gravatar
tester a dit :

non non, c'est pas moi hein et puis tu veux que je te dises un truc ? Je m'en tape. Moi je suis en train de tester le travail de sbgodin et vu le nombre de dl, je pense que je suis le seul à m'intéresser à son travail...vive la solidarité :(

gravatar
Julien et Nel a dit :

@tester :

J'avais essayé à une époque de modifier blogotext, c'est comme ça que j'ai commencé à coder uag au final. J'ai toujours eu du mal à comprendre le code des autres, mais je pense que c'est le cas de beaucoup. Il faudra que je vois la différence entre la version de timo et les patchs de sbgodin.

Sinon pour le troll ça peut être n'importe qui, on aime tous troller :)

gravatar
Sbgodin a dit :

@tester : Tu parles de quels nombre de dl ? Je ne vois que ceux correspondant aux archives téléchargeables. Mais ce sont des copies de sauvegardes, les originales étant chez Timo. Merci de ton soutien moral :-) Mais mes travaux ne sont dirigés, à la base, que vers Timo. J'utilise le blog, il récupère mes modifs. Donc si personne ne mâte mes sources, aucune importance tant que ça se retrouve dans Blogotext.

@Le Hollandais Volant : j'ai une idée concernant l'usurpation d'identité. Tu veux bien jeter un coup d'œil à l'idée des comptes certifiés ?

gravatar
tester a dit :

Bah oui j'ai dl les archives :) Plus haut tu parlais d'ajouter l'édition+inscription à blogotext...je donc testé ! Enfin bref :)

gravatar
Le Hollandais Volant a dit :

@Sbgodin : je sais que c’est un soucis, l’usurpation d’identitié là, mais je veux pas que BT soit un générateur de spam. Commenter doit rester simple, sinon on ne s’en sort plus.

Au pire on utilise plutôt un vizhash basé sur (pseudo+email+IP), mais c’est lourd…

gravatar
Silversthem a dit :

@Le Hollandais Volant : tu save un tableau avec comme clé les pseudos et comme valeurs les mdp, tout simplement ( une option, "sécuriser mon compte" ).

gravatar
Sbgodin a dit :

@Le Hollandais Volant : Lorsque l'utilisateur a choisi de suivre l'échange par courriel, il n'y aucun envoi de courriel supplémentaire car les liens dans le courriel sont authentifiants. S'il ne suit pas le fil, un seul courriel est envoyé au premier commentaire à authentifier. Ensuite, tant que le navigateur retient l'authentification (cookie, storage, etc.) il n'y a pas d'envoi de courriel supplémentaire.

Le vizhash fait reposer l'authentification sur le lecteur du blog. C'est à lui de voir si les dessins correspondent, ce qui n'est pas facile s'il y a plusieurs pages (pure hypothèse) ou si l'utilisateur authentifié poste depuis une autre IP. Les comptes certifiés font reposer l'authentification sur le blog.

Concrètement, tous ceux qui postent de façon récurrente ici laissent les cookies et mémorisent leurs informations (pseudo, email, etc.). Pour ceux-là, il ne s'agit que de cocher une case.

P.S. Ce serait super si tu désactivais le rappel des anciens totaux du captcha des commentaires ^^

gravatar
Le Hollandais Volant a dit :

@Silversthem : ah oui je vois !
Mais ça me force à intégrer aussi un système pour réinitialiser le mot de passe, tout ça… Pas vraiment light une fois qu’on ajoute ça. Ça va devenir un wordpress après (j’ai failli crier quand j’ai revu le panel par défaut de WP y’a 1 semaine).

Autrement…
Concernant mes bench : je constate que si j’utilise des champs SQL de type plus approprié (le LONGTEXT, c’est un texte qui peut aller jusqu’à 4'000'000'000 de caractères : je doute que ce soit approprié pour un titre d’article). J’ai diminué à MEDIUMTEXT pour le contenu d’un article (16'000'000 de caractères, le TEXT de 65'000 chars me semble léger pour une limite pour un article : ça fait 6 fois mon plus long article).
J’ai aussi diminué à TINYINT où les valeurs sont juste de 0 ou 1.

Une fois ceci fait, les tests sur SQLite montrent qu’il prend en compte l’INDEX. C’est assez déconcertant, vu que la doc indique qu’SQLite se fiche de la taille (contrairement à MySQL).

gravatar
Le Hollandais Volant a dit :

@Sbgodin :
Ensuite, tant que le navigateur retient l'authentification (cookie, storage, etc.) il n'y a pas d'envoi de courriel supplémentaire.

Ouais mais perso j’utilise des tas d’appareils différents, et des navigateurs différents aussi… Voyons : 2 OS sur l’ordi avec 3 navigateurs sous Linux et 5 sous W$, mon smartphone, avec 2 navigateurs… Ça fait plus de 10 instances à gérer.
Je préfère encore la solution avec le mot de passe stocké (ou plutôt son hash salé, poivré comme vous voulez) : plus pratique pour l’utilisateur. Et utiliser un cookie pour retenir l’authentification à ce moment là.

Pour le rappel : excellente idée, merci ! (Opera ne dispose pas — à mon grand regret — de moyen pour retenir les champs, donc je n’ai pas ce soucis).

gravatar
Sbgodin a dit :

@Le Hollandais Volant : Si tu peux accéder à tes courriels depuis chacun d'entre eux, alors il te suffira de cliquer sur l'un des liens authentifiants du courriel.

Quand quelqu'un répond sur un fil, je reçois ce type de lien :
http://lehollandaisvolant.net/index.php?d=2013/03/01/23/50/10-les-limites-de-blogotext#idaace5a

Ça contient l'id de l'article et du commentaire visé. Il suffirait d'y rajouter un jeton :
http://lehollandaisvolant.net/index.php?d=2013/03/01/23/50/10-les-limites-de-blogotext&j=8baf5575075aa2ac757fceb43221eb9d#idaace5a

gravatar
Arthur a dit :

En tout cas, c'est clair que la différence est très voyante. Je n'aurai pas pensé que SQLlite était tant différent que MySQL !

gravatar
Le Hollandais Volant a dit :

@Arthur : En fait c’est moi qui suis dyslexique du code en SQL ^^'.

Après quelques ajustements, SQLite est (en local) aussi rapide que MySQL, partout… sauf sur la page des commentaires liste Admin.

Par contre, seul bémol : si les utilisateurs souhaitent utiliser ces performances, ils leur faudra tout exporter la BDD, supprimer le fichier .sqlite puis ré-importer. Ou alors bricoler un ALTER TABLE, mais SQLite n’aime pas trop ça.
Il sera aussi possible de mettre la prochaine version à jour normalement et continuer comme si de rien n’était, c’est juste qu’on profitera pas des améliorations.

Je pense que je vais repasser sur SQLite sur mon site du coup. Du moins pour voir quelques jours. (Le SQLite a l’avantage que la sauvegarde de la BDD est beaucoup plus simple).

gravatar
GoustiFruit a dit :

Je me demande si l'usage réduit des ressources avec MySQL ne vient pas du cache intégré ?
Est-ce que tu utilises un cache sur ton site, ou est-ce que chaque visite provoque la répétition des mêmes requêtes, même si aucun changement n'a eu lieu ?
Sinon si tu veux t'amuser avec un CMS bien plus sympa que WP, je te conseille PW. Pour ProcessWire :-)


Opera ne dispose pas — à mon grand regret — de moyen pour retenir les champs, donc je n’ai pas ce soucis


Je n'ai pas compris, de quoi tu parles ici ?

gravatar
Julien et Nel a dit :

Pour résumer, quelque soit le champs de formulaire je crois (textarea, input, etc).

Si j'ai bien compris, ceci est normalement pour améliorer la sécurité.

gravatar
Guenhwyvar a dit :

@Julien et Nel : Ouais, enfin, y'a la navigation privée si on veut pas laisser de traces. Ou même une option à activer, une case à cocher quelque part dans un menu, ce serait mieux que comme c'est là.

gravatar
jefaispeuralafoule a dit :

Je regardais un truc dans le fil de la discussion: la gestion de la date.

Pour avoir de bonnes performances en gestion de la date, rien ne vaut un champ véritablement "Date", car il est associé au timestamp, et donc permet des opérations très optimisées de recherche et surtout de tri. De là, dans ton cas, vu que tu stockes la date de chaque commentaire, quel est le format de la dite date? Si c'est du texte, là oui c'est un souci pour les performances.

Enfin bon, je ne suis pas non plus fanatique de l'incrémentation d'id formaté par rapport à une date, du fait que cela peut poser d'autres soucis, comme la nécessité de faire un traitement de la zone pour y pêcher la donnée. Oui, on a un gain de place, mais pas de performance.

Au-delà de ça, je pense que tu as déjà pensé à cette problématique;)

gravatar
GoustiFruit a dit :

@Le Hollandais Volant : Ctrl+F12 puis onglet "Formulaires" et là tu peux saisir un certain nombre d'informations (Nom, Prénom, Email, ...) pour faciliter la saisie des formulaires. Ensuite quand tu te trouves sur un champ texte, tu saisis la première lettre et Opera te propose les choix correspondants, ou bien tu appuies sur la touche [Down] de ton clavier, ou clic-droit et "Insérer une donnée personnelle".
Sinon il y a une extension "AutoComplete" (et peut-être d'autres) mais je n'ai jamais essayé, je n'en ai pas l'utilité en dehors de la fonction "Formulaires".

gravatar
GoustiFruit a dit :

@jefaispeuralafoule : Je ne vois pas non plus l'intérêt de cet ID basé sur une date, autant mettre la vraie date !?

gravatar
Le Hollandais Volant a dit :

@jefaispeuralafoule : Disons que la date comme ça n’est pas beaucoup utilisée en tant que date. Pour le tri j’utilise effectivement une comparaison de l’id, genre 201201% pour tous les articles de janvier 2012. Je pense que faire un "between" reviendra au même, que ce soit sur un INT ou un DATE.

Concernant l’ID, je l’ai juste mis là pour avoir un truc "unique" et indépendant de tout traitement. Les autres (bt_id) ou (bt_date) ne sont pas fiables (deux commentaires au même instant par exemple). Changer tout ça est possible, mais peu urgent.

@GoustiFruit : je connais est j’utilise :p
Mais c’est quand même plus limité que dans Firefox. Concernant les extensions, c’est très simple : aucun n’a jamais fonctionné correctement jusqu’à présent. Ils utilisent pratiquement tous le stockage HTML5…

gravatar
Petitkoalak a dit :

Je pense avoir lu une grande partie de vos commentaire, et ce que m'étonne un peu, c'est que vous avez très peu parlé de mise en cache !
Pour éviter les latences avec la bdd, il n'y a pourtant rien de mieux que de la court-circuiter, non ?
Ce serait rentable aux niveaux des articles déjà, tu fais très peu d'édition, il te suffit de faire un cache en html et de le regénérer à l'édition, les visiteurs n'auront plus la latence accès bdd + mise en page, un gain de temps considérable.
Pour les commentaires, comme tu ne proposes pas d'édition, ni de suppression de commentaire, tu n'es même pas obligé de les faire entrer dans la bdd (c'est quand même mieux, mais quand on parle optimisation des perfs, on parle optimisation des perfs :P) tu fais de nouveau un cache et tu rajoutes à la fin de ce fichier les commentaires à chaque nouveau commentaires postés.
Et pour éviter une recherche trop longue, suffit de les classer dans des dossiers (années au moins, voir mois) avec un nom qui convient pour t'y retrouver et poum le tour est joué !
Je pense que le cache est une des meilleurs solutions pour les "grosses" structures, en tout cas plus il y a d'accès BDD plus le cache devient rentable...

Pour l'identification, j'avais forké un plugin wordpress "MonsterID" qui est aussi un hash visuel, mais beaucoup plus fun et plus joli qu'un identicon ou un wavatar (je parle dans la version 2 de monsterID) et tu peux aussi cacher les monsterID déjà générés avec le hash correspondant comme nom

Le cache c'est la vie :D

gravatar
Silversthem a dit :

@Petitkoalak : c'est vrai que le cache c'est cool, puis j'ai l'impression que php à des fonctions toutes prêtes, ob_start et la série des ob, en 5 lignes tu peux faire un système de cache performant et rapide ;)

gravatar
tester a dit :

on s'en fout des alternatives à disqus made in "je te contrôle". Timo gère avec magistrat son blog, avec le recul qui s'impose compte tenu de l'affluence et des greffons parasitaires suceurs de sperm à la mords-moi-le-noeud débalant de partout.

Ceci dit, bienvenu dans l'irréel Nico admin...

gravatar
Sbgodin a dit :

@tester : Juvia est développé en Ruby. Personnellement Gem' pas trop mais c'est surtout incompatible avec Php. En plus, ce serait trop de gérer les commentaires dans un autre circuit (même en Php) que le blog lui-même. Ou alors, il faudrait externaliser. Pour ma part, je préfère largement conserver les commentaires au sein du blog. Il faut juste optimiser le travail.

Téléchargez le source et envoyez vos patchs à Timo. Il a un record de courriel à battre cette année ;-)

gravatar
Le Hollandais Volant a dit :

@Sbgodin : Oui, si le serveur a du mal avec la gestion actuelle des commentaires, ça ne risque pas de s’arrager avec un service externe au script et hébergé lui aussi en local.
Je ne sais pas comment il marche, mais s’il récupère les commentaires en dehors de MySQL (directement dans les fichiers de ce dernier), Perl serait plus performant, il est fait pour ça.

Ben y’a des jours où j’ai beaucoup plus de courriels que d’autres. 1 seul aujourd’hui. Et la journée vient de se terminer :D.

gravatar
Fred a dit :

Les solutions libres Disqus-like ont quand même pas mal d'intérêts de trouve.
1) Si on a un hébergement gratuit et limité, et qu'on utilise un service type Juvia pour son blog, alors on peut carrément envisager d'avoir un site entièrement statique, où les performances seront inégalables, malgré l'hébergement minimaliste.
2) Dans le cas où on aurait pas confiance en un fournisseur de service externe (au niveau de la confidentialité des données, au niveau de la fiabilité du service) et qu'on a un serveur dédié, on peut l'installer chez soi.
3) De cette manière on peut centraliser les systèmes de commentaires pour tous les types d'applications qui peuvent en avoir besoin : blog, articles, forums, wikis, galeries photos / vidéos, shaarli, etc. Pas besoin de re-développer tout un système à chaque fois.
4) Si le service est conçu de manière à optimiser ce pour quoi il a été fait (insertion et surtout récupération des commentaires), il peut se révéler plus performant qu'un système intégré au sein du blog moyennement optimisé.

Pour les visiteurs, si le service est bien intégré, la différence ne se voit même pas.

gravatar
Sbgodin a dit :

@Fred : Ton cas 2 contredit ton cas 1 puisque si on un serveur dédié, on pourrait préférer d'avoir un système de commentaire propre plutôt qu'un service externe.

Le point 3 envisage de tout commentariser. C'est à mon avis un bon cas d'utilisation : quand on n'a pas les moyens de maintenir/installer un truc avec des commentaires. Au prix de la dépendance à un service externe, avec les soucis de vie privée que cela implique.

Pour certains visiteurs, ce n'est pas transparent. Genre celui qui bloque les services externes comme la publicité...

gravatar
Giggs a dit :

Attention avec les indexes il faut être vigilent sur le type des données.
Est-ce que bt_statut est bien une chaine de caractères? Car si le type n'est pas respecté, l'index ne sera jamais utilisé!

SELECT * FROM commentaires WHERE bt_article_id=? AND bt_statut='1' ORDER BY bt_id


Ici tu peux appliquer un indexe composé des 2 colonnes :

CREATE INDEX TestIndex ON commentaires (bt_article_id, bt_statut);

D'une manière générale il te faut absolument travailler avec les explain plan pour savoir ce qui est fait...

gravatar
Le Hollandais Volant a dit :

@Giggs : comment ça respecter le type ?
bt_statut est un entier, mais en quoi ça gêne pour l’index qui est sur bt_id (et un entier) ? (ceci dit, je vais retirer les « ' » autour du « 1 », en effet ils doivent être retirés.

Le « explain » on m’en a parlé au dessus dans les commentaires, mais comment l’utiliser en PHP ??

gravatar
Giggs a dit :

Oui voilà il faut retirer les cotes ' ' de la requête à ce moment là ça sera bon.

EXPLAIN QUERY PLAN SELECT * FROM commentaires WHERE bt_article_id=? AND bt_statut='1' ORDER BY bt_id;

gravatar
Sbgodin a dit :

@Le Hollandais Volant : Le explain n'est pas à utiliser en php mais en connexion directe à la bdd. Ça peut se faire soit en ligne de commande, soit via un outil de type phpmyadmin.

gravatar
Le Hollandais Volant a dit :

Je viens de voir pour les EXPLAIN : maintenant il utilise les index. Par contre, je constate que ceci :
SELECT bt_id FROM commentaires
Est beaucoup plus lent que ça :
SELECT bt_id FROM commentaires ORDER BY bt_id

Dans le second il utilise l’index sur bt_id, mais pas dans le premier. D’un côté ça semble logique vu qu’il n’y a pas d’ordre. Mais c’est quand même déroutant…

Quand je dis "beaucoup plus lent", c’est genre 0,025s au lieu de 0,014s

gravatar
Guenhwyvar a dit :

Ouais, enfin, un centième de seconde en plus pour une requête, vu qu'à vue de nez tu dois avoir quatre requêtes pour afficher la page, ça reste raisonnable, quand même.

gravatar
Le Hollandais Volant a dit :

@Guenhwyvar : c’est pas ça, mais ça passe du simple au double, c’est ça qui est troublant.

Avec toutes les optimisations ces derniers jours, je suis passé de 0.2s à 0,03s pour la page principale et de 0,24 à 0,08s pour la page des commentaires côté admin (qui est la plus lente car en haut j’ai un menu déroulant avec le nombre de commentaires par auteur et un tri par mois. C’est ça qui prend beaucoup de temps.

Pour la page principale du blog, il y a en effet trois requêtes oui :
- articles principaux du blog
- le calendrier
- les derniers commentaires.

Ça peut aller plus haut si l’utilisateur décide d’ajouter la liste des tags.

gravatar
Guenhwyvar a dit :

Je parlais d'une page d'article, comme celle où on est. Je pensais à :
— article (titre, contenu, tags, etc.)
— commentaires de l'article
— calendrier
— derniers commentaires

Sur les quatre, y'en a au moins trois qui se mettent en cache facilement (c'est plus dur pour les commentaires de l'article, comme le format de la date change avec aujourd'hui, hier et avant).

gravatar
Guenhwyvar a dit :

@Le Hollandais Volant : Ouais, je me doute, mais du coup tu peux pas le mettre en cache, vu que ça change au fil du temps.

Les commentaires sont fermés pour cet article