boardz:journal10022020

Ceci est une ancienne révision du document !


Ajout de fonctions de mesure de performance

La première mesure était d'obtenir la vitesse d'intégration des logs, afin de savoir dans quelle mesure le Boardz sait “digérer” une volumétrie existante.

Les mesures ont donné : entre 250 et 360 logs / seconde, soit entre 900k et 1,3M logs par heure (en régime continu). Les tâches d'alimentation prévoient deux paramètres :

  1. La taille max du “lot de logs” pour une requete.
  2. Un “temps de refroidissement” de l'alimenteur,, temps d'attente entre deux salves d'alimentation. Le but est de maîtriser la “charge continue ajoutée” à un moodle en production pour aspirer les logs.

Le plugin moodle d'extraction des logs (report_etl) a du être légèrement corigé, d'ailleurs, pour éviter des pertes marginales d'échantillons entre deux requêtes successives.

Poursuite du travail sur les outillages de mesure (et indicateurs)

Le principe de sélection par composant/action (ex : forum / created_post) est très probablement trop simpliste, dans le cas de mesures qui portent sur une sélection d'actions multiples particulières. Dans le premier modèle, on ne peut faire qu'un choix d'une action unique, ou au mieux de “outiller les actions” d'un certain composant. C'est visiblement trop réductieur, lorsqu'il faut, par exemple associer deux événements particuliers des forums (created_discussion ET created_post) pour balayer l'espace “d'intervention participative” des utilisateurs.

Le modèle est en cours d'extension, afin de pouvoir choisir des combinaisons plus “riches” de composants/actions (par expression régulière). Le besoin adresse de toutes façons l'indicateur suivant à produire sur les divers “rendus”, puisqu'il faut aller chercher des actions précises dans plusieurs composants (devoir, base de données, quiz, forums évalués etc)

Futures préoccupations

Voir comment remonter les métadonnées relatives aux activations de demande d'achèvement. Certains indicateurs en parlent, il va donc falloir aménager une remontée de certaines données pour le prendre en compte.

Difficultés identifiées

  • Ergonomique : Comment mieux contrôler et vérouiler les interfaces (formulaires) pour éviter les “erreurs de configuration”, dans un système de configuration qui reste complexe
  • Testabilité : Même en ayant ajouté un autre site de nos clients, les données qu enous avons chez nous sont plutôt liées à un usage “formation continue”. Nous manquons pour l'instant de donées liées à une pratique “académique” pour valider le comportement de certains indicateurs. Par exemple, dans aucune de nos plates-formes se révèlent un usage “étudiant” significatif des forums.

Un travail sur une copie de vos données devrait permettre de “voir” mieux.


Sommaire du journal - Revenir au sommaire général

boardz/journal10022020.1581335200.txt.gz · Dernière modification: 2020/04/07 11:07 (modification externe)