C'est toujours le même problème que celui évoqué lors des discussions
précédentes : ça ne veut pas dire grand'chose... 
En plus, ça ne
mémorise que le dernier auteur, on risque donc de rater certains accès.
@ Antoine Pitrou <antoine@rezo.net> :
C'est toujours le même problème que celui évoqué lors des discussions
précédentes : ça ne veut pas dire grand'chose...En plus, ça ne
mémorise que le dernier auteur, on risque donc de rater certains accès.
Non, moi je trouve ça bien, ça alerte un peu, ça rassure un peu. En cas de
doute tu fais un mssage à celui que tu as vu retirer le truc (il faudrait
donc un icône d'imessage à côté du nom.
-- Fil
C'est toujours le même problème que celui évoqué lors des discussions
précédentes : ça ne veut pas dire grand'chose...
mémorise que le dernier auteur, on risque donc de rater certains accès.
C'est justement dans la ligne des discussions qu'on a déjà eu: ça n'est pas un système de verrouillage. C'est juste une indication pour éviter de se marcher sur les pieds. D'où la simplicité du procédé et la phraséo un peu floue.
C'est depuis hier sur uZine, et je trouve que le procédé s'est déjà avéré très pratique. C'est d'ailleurs plus l'absence d'indication "Machin est intervenu" qui est pratique: là on sait qu'on peut y aller sans se poser de question.
C'est depuis hier sur uZine, et je trouve que le procédé s'est déjà
avéré très pratique. C'est d'ailleurs plus l'absence d'indication
"Machin est intervenu" qui est pratique: là on sait qu'on peut y
aller sans se poser de question.
Oui, je suis d'accord que ça peut apporter quelque chose. C'est surtout
qu'il ne faut pas laisser croire que c'est infaillible. Quant à la
phraséo, bah, ça s'améliore.
Salut,
Suite aux problème avec l'huma, j'ai regardé une petite idée d'optimisation
hier. Le principe est que, quand on fait une sélection sur la table
d'articles, on fait des trajets assez gros sur le disque parce que les
textes sont pas minuscules (on peut compter en moyenne 5 à 10 Ko par entrée
dans la table). Or, en fait, on ne récupère in fine que très peu d'infos
par rapport à ce qui est consulté (par exemple les 10 derniers articles
publiés dans la rubrique N alors qu'on a auparavant tout trié par date).
J'ai fait deux trois petits tests en récupérant la base du diplo et en
la multipliant. Ca donne 32000 articles. J'essaie avec deux tables :
- table a, contient tous les champs recopiés en intégral
- table b, contient tous les champs sauf descriptif, chapo, texte, ps,
referers.
Pour un même nombre d'entrées, la table a fait 220 Mo ; la table b, 5 Mo.
Quand on teste diverses requêtes typiques retournant par exemple une dizaine
d'articles (affichage de rubrique ou de sommaire), les requêtes sur la table
b sont trois à huit fois plus rapides. Mieux, même quand on veut récupérer
les champs longs en faisant une jointure entre les tables, c'est toujours
beaucoup plus rapide. En clair :
SELECT a.texte FROM b LEFT JOIN a USING (id_article)
WHERE b.statut = 'publie' ORDER BY b.date DESC LIMIT 0,10;
est plusieurs fois plus rapide que :
SELECT texte FROM a
WHERE statut = 'publie' ORDER BY date DESC LIMIT 0,10;
(parce que la sélection se fait sur une table beaucoup plus compacte
et qu'on utilise au minimum la grosse table)
Ca veut donc dire qu'on pourrait un jour séparer la table spip_articles
en deux :
- spip_articles : id_article, id_rubrique, id_secteur, titre, surtitre,
soustitre, statut, date, visites
- spip_corps_articles : id_article, descriptif, chapo, texte, ps, referers
Ce qui permettrait de gagner pas mal de temps sur certains affichages,
et de rendre possibles la réalisation de gros sites type Huma
(plusieurs giga-octets d'articles).
Evidemment, de grosses, grosses modifs à prévoir dans le code....
a+
Antoine.
PS : en attendant, il faut penser à ajouter un index sur id_secteur,
de même que sur id_rubrique (je me suis rendu compte que ça manquait).
@ Antoine Pitrou <antoine@rezo.net> :
- table b, contient tous les champs sauf descriptif, chapo, texte, ps,
referers.
Et quand le nombre de referrers déborde le blob du champ referrers? (NB:
quand on a plus de 65636 referrers...) que fait on ?
-- Fil
Fil wrote:
>
> Et quand le nombre de referrers déborde le blob du champ referrers? (NB:
> quand on a plus de 65636 referrers...) que fait on ?
4096 plutôt. Au choix :
1. on considère qu'on n'a pas besoin d'en savoir plus
2. on passe le champ en longblob
3. on se pose la question de l'utilité réelle de ce champ, dont la mise
à jour peut à mon avis charger un peu la base (champ de longueur variable)
C'est un champ qui oblige à stocker bcp de données pour au final une
info assez maigre. A discuter ?
a+
Antoine.
Hello,
Et quand le nombre de referrers déborde le blob du champ referrers?
Au choix :
1. on considère qu'on n'a pas besoin d'en savoir plus
2. on passe le champ en longblob
3. on se pose la question de l'utilité réelle de ce champ
Ou autre solution, on crée une table spéciale, avec un enregistrement
par referer. Plus léger, plus simple, "optionnalisable", ...
-Nicolas
Le champ referers est devenu plus ou moins inutile pour deux raisons:
- parce que les referers sont stockés en md5, donc c'est inutilisable;
- parce que ça ne teste pas de savoir si c'est un lien interne; du coup le chiffre est totalement farfelu, puisque ça compte les visites "normales" à l'intérieur du site. Sur uZine, l'article publié il y a quelques heures a déjà 6 referers, alors que je doute qu'il soit référencé quelque part. Donc le referer, qui devait servir à avoir une idée de la popularité d'un article à partir du référencement (sur le modèle de Google), ne sert plus à rien.
Il faudrait donc:
- repasser les referers en clair (je ne vois pas trop ce que ça trahit qui, par ailleurs, ne soit pas déjà connu par ailleurs); de cette façon on aurait une indication utile (savoir où l'on est référencé), et ça permettrait de nettoyer un peu la liste (par exemple considérer que "http://www.uzine.net", "http://www.uzine.net/" et "http://www.uzine.net/index.php3" et "http://www.uzine.net/sommaire.php3" sont le même referer);
- ne compter que les referers de l'extérieur, ce qui évite la multiplication mathématique des referers selon la taille du site et l'utilisation du moteur de recherche interne, et rétablirait son utilité initiale: la popularité façon Google. De cette façon, le critère {par popularite} calculé en fonction du nombre de hits et du nombre de referers reprendrait un certain sens.
(En gros, c'était le fonctionnement initial du système.)
ARNO*
Salut ARNO*,
Sur uZine, l'article publié il y a quelques heures a déjà 6
referers, alors que je doute qu'il soit référencé quelque part.
Tu oublies tous les sites qui listent les articles d'uZine par
syndication.
Pour le reste, je suis d'accord, sauf que rassembler automatiquement
les referers identiques en "nettoyant" les paramètres des URL est
impossible.
J'ai en la matière une expérience notable, puisque j'essaie de gérer
ça sur phpHeaven depuis plus de deux ans :
http://www.phpheaven.net/about/stats/referers.php3
J'ai actuellement plus de 30000 adresses de referers en attente de
filtrage dans ma base ...
-Nicolas
Hello,
> Le champ referers est devenu plus ou moins inutile pour deux raisons:
> - parce que les referers sont stockés en md5, donc c'est inutilisable;
De ce point de vue il a toujours été inutile. Avant qu'il soit stocké
en md5, on n'affichait aussi que le nombre de referers, comme aujourd'hui.
Il fallait farfouiller dans la base pour savoir par quoi un article était
lié, ce qui est peu exploitable
Le but initial (enfin, celui qu'on a mis en avant à l'époque) était de
pouvoir simplement compter les referers afin de faire ce qu'on espérait
être une mesure de popularité tenant compte du nombre de liens externes
en même temps que du nombre de visites brutes (c'est un peu comme Google,
en le disant vite ;-)). Dans ce cadre, le md5 était suffisant, prenait
moins de place, et permettait de ne pas enregistrer d'éventuelles infos
indiscrètes (URLs "privées"...).
> - parce que ça ne teste pas de savoir si c'est un lien interne; du coup
> le chiffre est totalement farfelu, puisque ça compte les visites
> "normales" à l'intérieur du site.
Ce n'est pas tant ça qui pose problème car le nombre de liens internes
est à peu près le même d'un article à l'autre, sur un même site, du moins
y a des chances. (à la limite, ça permet même d'avoir des infos pour
savoir si la navigation du site est efficace)
Par contre, il y a d'autres choses :
- plein d'entrées parasites (brouteurs fantaisistes, mal réglés,
liens depuis des mails, etc)
- des URLs plus ou moins "alternatives" correspondant en fait aux mêmes
pages d'entrées
- surtout, des problèmes de performances : on insère des données dans la
base à chaque accès à un article, ce qui est fortement susceptible de
faire mouliner le serveur s'il y a beaucoup de requêtes (genre hébergeur
mutualisé). En comparaison, incrémenter le compteur de visites, c'est
modifier un champ de taille fixe, c'est bcp plus indolore (à mon avis).
- ça finit, mine de rien, par prendre de la place dans les tables
(dépend des sites, bien sûr :-)).
Enregistrer tous les referers, exhaustivement, ne me paraît pas très
viable ni très intéressant. Si on veut un module de statistiques sympa
(pour moi ce n'est pas vraiment une priorité), je pense qu'il faudrait
traiter les referers de deux façons :
- extraire le début de l'URL (en limitant par exemple au premier
sous-dossier, ça permet d'englober à la fois les sites en nom de domaine
propre et les sites hébergés en sous-répertoire). En profiter pour
nettoyer. Exemple :
"http://WWW.mAchin.com/a/b/c/truc.asp?z=5" devient "machin.com/a"
- pour un certain nombre d'expressions régulières prédéfinies (ça
se récupère dans la config par défaut de Webalizer, je pense),
extraire automatiquement les chaînes de recherche des principaux
moteurs :
"http://www.google.com/?q=roberts" donne "roberts"
Les deux infos prennent en fait peu de place (la première donne
plus de doublons, donc moins d'insertions, que les referers
en entier, et la deuxième ne surgit qu'occasionnellement), et
restent pertinentes. Mais même là, il faut faire gaffe à ne pas
charger la base. Il y a des moyens sympas d'optimiser certaines
données non vitales sous MySQL (tables en mémoire, etc) mais
ce ne sera pas dispo ou autorisé sur tous les hébergeurs,
donc je ne pense pas que ça vaille le coup....
De toute façon, pour des vraies stats détaillées, on ne peut pas
utiliser un bousin en php avec une base mysql derrière. Il suffit
de voir les horreurs type "les visiteurs" (c'est vrai que l'exemple
est un peu extrême). Là, il n'y a plus qu'à traiter les stats
apache avec un prog dédié type webalizer.
a+
Antoine.
Bonsoir,
Enregistrer tous les referers, exhaustivement, ne me paraît pas très
viable ni très intéressant.
En effet.
extraire le début de l'URL (en limitant par exemple au premier
sous-dossier, ça permet d'englober à la fois les sites en nom de
domaine propre et les sites hébergés en sous-répertoire)."http://WWW.mAchin.com/a/b/c/truc.asp?z=5" devient "machin.com/a"
Pourquoi virer 'http://www.' ??? Comment ensuite faire la différence
entre http://www.sousdom.example.com/ et http://sousdom.example.com/
qui peuvent être différents ?
pour un certain nombre d'expressions régulières prédéfinies (ça se
récupère dans la config par défaut de Webalizer, je pense), extraire
automatiquement les chaînes de recherche des principaux moteurs :"Google; donne "roberts"
Il faut garder l'info disant qu'on vient de Google tout de même ...
De toute façon, pour des vraies stats détaillées, on ne peut pas
utiliser un bousin en php avec une base mysql derrière.
Certes.
Il suffit de voir les horreurs type "les visiteurs" (c'est vrai que
l'exemple est un peu extrême).
Arrête, je me suis déjà fait lynché après avoir dit ça !!!
Sans blague, je n'ai pas osé jeté un nouvel oeil, le seul qu'il me
reste après un premier échec, mais il paraît que les dernières
versions ont été "optimisées".
Un meilleur exemple de soft de stats à mon sens est phpOpenTracker,
mais il ne semble pas gérer cette reconnaissance des moteurs de
recherche, ce que fait Les Visiteurs ...
-Nicolas