[spip-dev] Nouveau systeme de decompte des visites

Dev
1

Salut,

Je viens d'uploader une modif assez importante: il s'agit d'un nouveau systeme de decompte des visites et des referers.

Avant d'expliquer le fonctionnement, les imperatifs de la chose:

(1) fournir le minimum vital d'informations que peut attendre un webmestre; ça ne prétend donc pas concurrencer un Xiti ou un Visiteurs (de toute façon, avec un machin façon Xiti, faut passer des heures à expliquer aux gens ce que signifient des nombres dont, finalement, ils se contrefoutent...). Les deux trucs principaux qu'attendent les webmestres: le nombre de visites par jour, l'évolution des visites, et les sites extérieurs qui mènent vers le site (accessoirement, les requêtes dans Google, parce que c'est vraiment trop drôle...)

(2) éviter à tout prix la surcharge pondérale. Comme Antoine, je n'ai pas testé la dernière version de Visiteurs, mais la dernière fois que j'avais essayé sur uZine, ça bouffait plus de place dans la base de données que le site lui-même; j'avais aussi essayé sur un autre site, et là les temps de calcul étaient énormes...

(3) ne pas ralentir le fonctionnement du site par des requêtes mySQL permanentes.

(4) limiter le nombre de nouvelles tables. Les 200 tables des Nukeries, perso ça me gave (même si, sans doute, ça fait du code plus élégant).

Le principe est celui d'un "fichier de logs" passé régulièrement par une moulinette qui en extrait les infos intéressantes. Ici, c'est tout en mySQL, mais c'est en gros le principe.

A. Première étape: enregistrement des "logs"

2

Hello,

Je viens d'uploader une modif assez importante: il s'agit d'un
nouveau systeme de decompte des visites et des referers.

Pas mal ton nouveau système, bravo !

Bon, allez, j'ai quelques remarques, tout de même ... :wink:

Les deux trucs principaux qu'attendent les webmestres: le nombre de
visites par jour, l'évolution des visites, et les sites extérieurs
qui mènent vers le site (accessoirement, les requêtes dans Google,
parce que c'est vraiment trop drôle...)

Ca fait donc 3 et non 2 ... :stuck_out_tongue:

J'ajouterais qu'une petite stat sur la répartition horaire des visites
peut être sympa. C'est vrai que ça multiplie la taille de la table par
24 si le site est beaucoup visité, donc ça pourrait être une
option ... :wink:

Les 200 tables des Nukeries, perso ça me gave (même si, sans doute,
ça fait du code plus élégant).

Je ne suis pas franchement sûr que ça fasse du code plus élégant,
non... :wink:

Chaque hit est donc enregistré sous la forme:
- date simplifiée (tout est à minuit)

Pourquoi ne pas conserver la date complète et ainsi permettre
notamment les stats de répartition horaire ?

C'est pas plus compliqué à stocker, tu n'as pas à "calculer" le minuit
de la date courante, et ça donne plus d'infos ...

- page visitée (sous la forme "article21", "breve23"...) (je
pourrais encore alléger à cet endroit, parce que finalement je
n'exploite que les articles)

Pourquoi se limiter aux articles ?
Tu prend l'info dans le contexte, c'est ça ?

Pour les "visites", je me suis pas fait chier: ce sont les ip
différentes chaque jour.

Donc une personne qui navigue avec un anonimizer qui fait "tourner"
l'IP a chaque requête va être vu comme autant de visiteurs
différents... :frowning:

Encore un truc où une gestion de session serait un plus !

[Referers]
à intervalle régulier (pour l'instant, 7 jours), on efface les
referers qui n'ont provoqué qu'une seule visite.

Donc tout referer qui utilise des ID de session en URL n'entrera
jamais dans les referers, pas terrible.

supprimer tous les referers ultra-ponctuels (recherches dans moteurs
de recherche, URL transmise dans un mail...).

Je préfère savoir qu'on est tombé sur mon site une fois depuis un
moteur de recherche (signe de bon référencement), plutôt que 1000 fois
depuis un petit site qui utilise ma syndication. Pas vous ?

pour analyse les requêtes des moteurs, j'ai directement repris 2
fonctions dans Visiteurs, avec notamment un fichier de config très
simple à modifier, que j'ai placé dans /data/engines-list.ini

A priori, tu as pris tout ce qu'il y a d'intéressant dans Les
Visiteurs ... :wink:

Voilà, le truc est fonctionnel, même si pas finalisé (je teste sur
uZine, mais avec seulement 2 jours d'entrées, ça ne va pas loin...).

Si on a maintenant retrouvé la bonne version de SPIP en CVS, je vais
tester, et je vous tiens au courant.

-Nicolas

3

J'ajouterais qu'une petite stat sur la répartition horaire des visites
peut être sympa. C'est vrai que ça multiplie la taille de la table par
24 si le site est beaucoup visité, donc ça pourrait être une
option ... :wink:

Mouais...

Le fait que ce soit PHP qui logue (il n'est pas fait pour ça) les stats
de apache, ça me paraît quand même faire double emploi... Encore un trou
dans le système de fichiers (chaque autorisation d'écriture est une
faille potentiellement exploitable en cas de trou sur un script.

Apache+Webalizer, ça ne vous va pas ?

Ou alors, il faudrait au moins pouvoir le désactiver....

> Les 200 tables des Nukeries, perso ça me gave (même si, sans doute,
> ça fait du code plus élégant).
Je ne suis pas franchement sûr que ça fasse du code plus élégant,
non... :wink:

Oauis, mais ça c'est historique :wink: Au vu de l'histoire tourmenté des
débuts de nuke, y'a une dizaine de types qui se sont penchés dessus...
chacun à sa façon... (!) Ca fait un rude pb de conception au final.

Donc une personne qui navigue avec un anonimizer qui fait "tourner"
l'IP a chaque requête va être vu comme autant de visiteurs
différents... :frowning:

Encore un truc où une gestion de session serait un plus !

Ben v'la... écrire un WebTrends ou un webalizer dans spip ça va faire
une rude usine à gaz !

> supprimer tous les referers ultra-ponctuels (recherches dans moteurs
> de recherche, URL transmise dans un mail...).
Je préfère savoir qu'on est tombé sur mon site une fois depuis un
moteur de recherche (signe de bon référencement), plutôt que 1000 fois
depuis un petit site qui utilise ma syndication. Pas vous ?

D'accord....

4

Le fait que ce soit PHP qui logue (il n'est pas fait pour ça) les
stats de apache, ça me paraît quand même faire double emploi...

Il ne logue pas vraiment la même chose, et peu d'utilisateurs de SPIP
ont accès aux logs de leur serveur HTTP (qui n'est pas forcément
Apache).

Encore un trou dans le système de fichiers

???

C'est en base que ça se passe, là ...

Apache+Webalizer, ça ne vous va pas ?

Je répète :
"peu d'utilisateurs de SPIP ont accès aux logs de leur serveur HTTP"

Encore un truc où une gestion de session serait un plus !

Ben v'la... écrire un WebTrends ou un webalizer dans spip ça va
faire une rude usine à gaz !

Quel rapport avec des sessions ???

-Nicolas

5

> Encore un trou dans le système de fichiers
???
C'est en base que ça se passe, là ...

Beuh non, ARNO* disait qu'il logguait dans un fichier... non ?

>> Encore un truc où une gestion de session serait un plus !
> Ben v'la... écrire un WebTrends ou un webalizer dans spip ça va
> faire une rude usine à gaz !
Quel rapport avec des sessions ???

Euh... ouais, si elles sont utilisées pour d'autres choses alors.
J'ai quand même l'impression qu'il va falloir commencer à implémenter
tout un tas de trucs pour logguer 2/3 stats, puis faudra rajouter une
gestion plus fine, le suivi des visiteurs, les graphes de pointes, qui
va où, la part admin/privée, déduire les hits de googlebot etc...

6

C'est en base que ça se passe, là ...

Beuh non, ARNO* disait qu'il logguait dans un fichier... non ?

Non, c'était un système de logs simple au lieu de mises à jours, mais
tout de même en base ...

Quel rapport avec des sessions ???

Euh... ouais, si elles sont utilisées pour d'autres choses alors.

Elles devraient être utilisées pour l'auth, pour des infos à trimbaler
lors de la navigation, pour ne pas avoir à requêter la base à chaque
page ... plein de choses possibles très simplement.

-Nicolas

7

Elles devraient être utilisées pour l'auth, pour des infos à trimbaler
lors de la navigation, pour ne pas avoir à requêter la base à chaque
page ... plein de choses possibles très simplement.

Si on pose une session pour tous les visiteurs de l'espace public,
ça pose des problèmes de garbage collection. Et puis je ne vois pas
l'intérêt.

8

Elles devraient être utilisées pour l'auth, pour des infos à
trimbaler lors de la navigation [...]

Si on pose une session pour tous les visiteurs de l'espace public,
ça pose des problèmes de garbage collection.

Je ne vois pas pourquoi ça poserait des problèmes de GC, mais je
pensais de toute façon uniquement à la navigation des utilisateurs
authentifiés.

Et puis je ne vois pas l'intérêt.

OK.

-Nicolas

9

Salut,

Je viens d'uploader des compléments sur le système de décompte des visites/referers.

Mise à jour de la table spip_articles
- L'ancien "referers" disparaît, et est remplacé par un champ "referers" qui est un entier.
- Ajout d'un entier "popularite".

Une fois par jour ("optimisation" + 19 heures, histoire de pas le faire en même temps que les autres), il y a une optimisation des referers.

- Il n'y a plus l'effacement systématique des referers qui ont fait une seule entrée, âgés de plus d'une semaine. C'est remplacé par un calcul plus fin.

- Pour chaque type ("tout", "articlexxx"...), on conserve 100 plus importants referers (en nombre de visites apportées) et on vire les autres, s'ils sont âgés de plus d'une semaine.
De cette façon, le nombre total d'entrées dans spip_visites_referers est relativement fixe: 100*nombre d'articles; avec un "surplus" pour les referers âgés de moins d'une semaine.

- Je récupère le total des "entrées directes" (c'est-à-dire le total des visites des referers) pour chaque article, et je le réinjecte dans spip-articles, dans "referers". De cette façon, le champ "referers" de chaque article est le nombre d'entrées directes sur l'article.

- Pour chaque article, calcul de la popularité. Il s'agit du nombre de visites multiplié par le nombre d'entrées directes (on pourra facilement changer le mode de calcul, par exemple en mettant les visites au carré), divisé par le maximum sur le site. C'est donc un entier, le plus populaire étant fixé à 1000000 (un million). Il faudra voir à l'usage, mais cela devrait permettre les calculs plus élaborés avec la date de l'article (les essais précédents avaient tous avorté, car le chiffre, calculé "dans l'absolu", était beaucoup trop variable d'un site à l'autre; là, on a un chiffre dont on connait la valeur maximum, les autres articles étant calculés relativement à ce maximum).

10

Salut,

Upload de plusieurs modifications d'interface pour la gestion des statistiques. Rien d'important, mais ergonomie et lisibilité:

- les tableaux graphiques d'évolution des stats affichent des barres horizontales facilitant la lecture des valeurs; affichage de la valeur maximale du tableau, total des entrées;
- sur page d'évolution, affichage des autres articles récents, facilitant la navigation;
- sur page des articles récents et "tous les articles", choix de la présentation par visites, par entrées directes, par popularité, avec petite explication quand nécessaire;
- dans afficher_articles, si choix d'afficher les stats, ça affiche en plus le nombre d'entrées directes;
- sur page des articles, lien vers les statistiques de cet article;
- sur page d'évolution des stats, retour vers l'article.

ARNO*

11

Bon, en fait, c'est pas uploadé, le CVS de Tux vient de me lâcher entre les pattes. :frowning:

ARNO*

12

Et là c'est revenu. Grmmmml.
ARNO*