Ok, donc on s'oriente donc vers une solution à base d'analyse de logs dans un premier temps. En regardant rapidement les logs existantes, sur 40 Mo de logs (~160 000 lignes) en une journée, les lignes qui nous intéressent sont celles qui sont liées aux requêtes de type GET sur le contenu. Enlevant tout ce qui est /forums, /media/, /static/, /membres/ il ne nous reste au final qu'environs 40 000 lignes de logs à parser et à stocker.
Le bonus étant que ça tiendrait même dans une BDD MySQL vu la forme des données.
Si ça convient à tout le monde, je mettrais à jour le premier POST dans ce sens en précisant la nouvelle architecture ainsi que les 7 métriques qu'on doit obtenir.
Si jamais ça peut aider, le script de parsing de logs utilisé par Piwik semble fait en Python.
C'est clairement le genre d'outil qui pourrait être utile s'il était compatible python3 (à garder sur le coude si jamais la migration n'est pas trop compliquée).
Pour obtenir des statistiques sur des tutoriels, on a le choix entre 2 types de fournisseurs de données.
Les logs du serveur web : dans le cas de ZdS il s'agit des logs nginx qui nous permettent d'obtenir 7 métriques sur les 10 demandées par la communauté.
Les données de Google Analytics : disponibles au travers d'une API, il s'agit de données déjà calculées. On ne dispose donc pas de données de références.
L'option 1 quant à elle nous prive de 3 métriques sur 10, mais nous permet de rester dans des volumétries de stockages acceptables (le calcul n'est pas précis, mais on est dans la fourchette de 10Go à 15Go par an).
D’où la conclusion de partir sur l'option 1 et si à l'utilisation, les 3 métriques restantes nous manquent, les intégrer dans la v2 de la ZEP.
Ok, merci pour le récap' Puisque tu maîtrises les données avec tes jolis tableaux, les 3 métriques manquantes représente un fort pourcentage des votants comme "données que j'aimerais voir" ?
Si on considère que "Pourquoi pas" signifie plutôt pour, pour les trois métriques restantes, on a respectivement 82%, 76% et 88% des votants qui la veulent.
De toute façon, peu importe la solution choisie : ÀMHA il n'y a pas besoin d'une précision à la journée et il n'y a pas non plus besoin d'une mémoire infinie.
Une vision à la semaine, sur six mois, avec la possibilité pour les potentiels clients de l'API de sauvegarder au fur et à mesure (ce qui n'est pas une problématique du serveur, du coup), ça divise par 14 la taille estimée avec GA ;o. Ça ne serait pas suffisant ?
Moui. A titre d'exemple le tuto Arduino a mis près de 3 ans a arriver dans l’état ou il est aujourd'hui (et c'est pas fini), perso j'aimerais bien voir sur plus long que 6 mois histoire de voir si par exemple l'ajout de chapitres fait venir de nouveaux visiteurs ou au contraire si c'est toujours stable et sans impact.
On revient à 82% (métrique 2) , 58%(métrique 8) et 82%(métrique 10).
Donc il ne reste plus que les métrique 2 et 10 de vraiment importantes statistiquement parlant.
Une vision à la semaine, sur six mois, avec la possibilité pour les potentiels clients de l'API de sauvegarder au fur et à mesure (ce qui n'est pas une problématique du serveur, du coup), ça divise par 14 la taille estimée avec GA ;o. Ça ne serait pas suffisant ?
Ce n'est pas le rôle des client de l'API de sauvegarder de l'information, pour la simple et bonne raison que l'information de référence doit provenir de ZdS. Si on veut être capable de suivre l'évolution d'un tutoriel sur 1 an, 2 an (ce qui n'est pas rare), on a pas trop le choix.
Du coup, pour avancer, j'embraye sur la question de l'API REST. Je vous propose la spécification suivante (n'hésitez pas à donner votre avis) :
Premier jet de spec pour l'API des statistiques
Par souci d’homogénéité avec les autres API du site, les paramètres de restrictions (throttling) seront les mêmes que sur les autres modules. C'est à dire qu'un client disposant d'une clé pour l'API aura un nombre de requêtes autorisés largement supérieur à un client sans clé. Il sera donc possible d’accéder à l'API sans avoir de clé.
La différence sera au niveau de la durée du cache sur les requêtes. Étant donné que le traitement d'analyse/parsing/stockage de logs sera fait une fois par jour, nous devons avoir une taille de cache de 24h, invalidé à chaque lancement de la procédure d'analyse.
Les verbes de l'API
Tout client de l'API (y compris le site) ne doit accéder à l'API uniquement au travers de la méthode GET, il s'agit donc d'une API en lecture seule.
Les paramètres des requêtes
Les paramètres des requêtes sont les variables que l'on passent à une url de l'API sous la forme http://api_url/?v1=x&v2=yv3=z. Dans cet exemple, v1, v2, v3 sont les paramètres de la requête.
Les paramètres sont tous facultatifs, et en cas de non renseignement d'un paramètre, la valeur par défaut sera celle spécifiée dans le fichier de paramètre (le settings.py) de zds.
Le module des statistique devra donc autoriser les paramètres suivants :
start_date : AAAAMMJJ.
end_date : AAAAMMJJ.
start_time : HHMMSS.
end_time : HHMMSS.
depth: Int. il s'agit de la profondeur du json rendu (voir l'exemple)
page : Int
J'ai un doute sur les paramètres nommés en anglais, mais en Français c'est pas très beau. Dites moi ce que vous en pensez
Les URLs de l'API
L'API devra mettre à disposition des clients les URLs suivantes:
:content_type : représente le type de conteneur (article, tutoriel, chapitre, partie)
:content_id : représente l'identifiant du conteneur sur zds
J'hésite à mettre à disposition l'url /api/contenus/stats/visites/ censée renvoyer les stats globales de chaque tutoriel. ça me semble nécessaire mais je n'ai aucune idée de ce que ça demande comme puissance de calcul. Normalement le cache devrait aider, mais je n'en sais rien au moment ou j'écris ces lignes.
Un json d'exemple
Voici ce que je vise comme structure de json sur l'url /api/contenus/:content_type/:content_id/stats/visites/ pour vous donner une idée. On voit que là on a toutes les informations demandées dans la spec.
Je déteste dire ça en général, mais vu le temps que va à mon avis mettre cette PR pour émerger, je vais le dire quand même: à un moment, à cause de la ZEP-12 content_type n'aura plus beaucoup de sens et content_id sera unique quoiqu'il arrive (même si on rajoute des tribunes ou je sais pas quoi).
Je ne vois pas le problème de mettre les mots en français. Genre, en quoi total_visits est plus glamour que « total_visites » et start_date plus sexy que « date_debut » ?
Sinon, si vous décidez quand même de le laisser en anglais, il faut mettre depth et non deep.
@pierre_24 : Ah, ce n'est pas ce que j'avais compris moi . En regardant le nouveau modèle de la ZEP-12, de ce que j'ai lu des commentaires, on retrouve bien le fameux content_type et content_pk, pour les contenus publiés.
A quel moment je me suis perdu du coup ?
Je ne vois pas le problème de mettre les mots en français. Genre, en quoi total_visits est plus glamour que « total_visites » et start_date plus sexy que « date_debut » ?
Sinon, si vous décidez quand même de le laisser en anglais, il faut mettre depth et non deep.
@pierre_24 : Ah, ce n'est pas ce que j'avais compris moi . En regardant le nouveau modèle de la ZEP-12, de ce que j'ai lu des commentaires, on retrouve bien le fameux content_type et content_pk, pour les contenus publiés.
A quel moment je me suis perdu du coup ?
Tu ne t'es pas perdu, ils existent toujours. Ce que je veux dire par là, c'est qu'ils n'ont plus qu'un sens "sémantique" et non plus "physique", comme avant. Autrement dit, dans ce genre d'application, on pourrait s'en passer, et c'est pour ça que je soulève la question, en fait, si oui ou non c'est nécessaire de le préciser.
Ce que je veux dire par là, c'est qu'ils n'ont plus qu'un sens "sémantique" et non plus "physique", comme avant. Autrement dit, dans ce genre d'application, on pourrait s'en passer, et c'est pour ça que je soulève la question, en fait, si oui ou non c'est nécessaire de le préciser.
C'est bien le sens "sémantique" qui m'intéresse ici. Dans la logique REST, on va parler de ressource.
Le client de l'API qui voudra uniquement les statistiques des visites sur les articles n'aura qu'à requêter sur l'URL /api/contenus/article/stats/visites/. Si la notion de content_type n'existe pas, il devra se fader tous les types de contenu depuis l'url /api/contenus/, alors que le seul qui l’intéresse sont les articles.
Ce que je veux dire par là, c'est qu'ils n'ont plus qu'un sens "sémantique" et non plus "physique", comme avant. Autrement dit, dans ce genre d'application, on pourrait s'en passer, et c'est pour ça que je soulève la question, en fait, si oui ou non c'est nécessaire de le préciser.
C'est bien le sens "sémantique" qui m'intéresse ici. Dans la logique REST, on va parler de ressource.
Le client de l'API qui voudra uniquement les statistiques des visites sur les articles n'aura qu'à requêter sur l'URL /api/contenus/article/stats/visites/. Si la notion de content_type n'existe pas, il devra se fader tous les types de contenu depuis l'url /api/contenus/, alors que le seul qui l’intéresse sont les articles.
Bon en y réfléchissant je pense partir sur une nomenclature toute francisée. En relisant le message de Dominus ça ne me parait pas si étrange que ça finalement.
J'avoue ne pas avoir suivi la suite du débat car ça partait dans des détails un peu trop technique, mais au final, seuls les auteurs pourront avoir accès aux données ? Pourquoi ce choix ?
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
Puisque tu maîtrises les données avec tes jolis tableaux, les 3 métriques manquantes représente un fort pourcentage des votants comme "données que j'aimerais voir" ?
. En regardant le nouveau modèle de la ZEP-12, de ce que j'ai lu des commentaires, on retrouve bien le fameux content_type et content_pk, pour les contenus publiés.
