Export de données et performances serveur

Export de données et performances serveur

par Olivier Valentin,
Nombre de réponses : 8
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles

Bonjour à tous !

Je suis en train de préparer notre bascule de Moodle 3.1 vers la version  3.5.
Après un premier test de migration, j'ai essayé les plugins RGPD, et notamment la possibilité de télécharger l'ensemble des données utilisateur. Cela a parfaitement marché, à un détail : le temps de travail du Cron.

Notre serveur de test n'est équipé que de 4 Go de RAM, aussi le serveur a travaillé plus d'une heure et demi pour créer l'archive d'une seule personne ! Après intervention de la DSI pour le booster à 16 Go, cela n'a pris que 20 minutes. Notre prod est équipe de 20 Go, cela devrait donc prendre un temps équivalent. De plus, il s'agit de MES archives, avec mon compte admin. Forcément, y'a du travail... sourire Mais dès le moment où la table des logs est abordée, le travail est extrêmement long.

Ce temps reste toutefois problématique, car d'après ce que j'ai vu, Moodle n'attend pas la validation du DPO pour générer l'archive, et procède à une pré-récupération des données avant de générer la véritable archive de données personnelles. Si 10 personnes demandent leurs données, le Cron procédera 10 fois au travail de récupération ! 10 x 20 minutes, un serveur peut moyennement apprécier...

J'aurais donc souhaité savoir si d'autres personnes avaient déjà eu l'occasion de tester ce module de récupération des données, et le temps que le serveur a mis pour créer cette archive. De quelles configurations serveur (RAM etc.) disposez-vous ? Quelle est la taille de votre table de logs ? A-t-elle, elle aussi, mis un long temps pour être interrogée ?

Je précise que notre serveur de test tourne sous PHP 7.0.27 ; la version Moodle testée est la 3.5+ (Build: 20180614). Notre prod tourne/tournera bien sûr sous les mêmes versions.

Merci !Olivier VALENTIN

Moyenne des évaluations Utile (2)
En réponse à Olivier Valentin

Re: Export de données et performances serveur

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles

Bonjour à tous,

je fais un petit up de ce sujet pour simplement signaler les avancées de Moodle sur cette fonctionnalité.

Nous avons migré sur la version 3.5.2+ (Build: 20181027) depuis 3 semaines, et nous avons reçu (ça se fête !!! sourire ) notre première demande d'export de données personnelles !

Dans mon message précédent, j'avais fait remonté les difficultés de ce module (en tout cas pour nous...) à générer l'archive des données, ainsi que l'impossibilité de contrôler le travail du cron.

Sur le plan procédural, rien n'a changé : un étudiant qui effectue sa demande lance immédiatement (au passage du cron) le travail de récupération des données sur Moodle, sans aucune intervention de l'admin ou du DPO. L'éventuel problème posé par 10 personnes lançant une demande d'export en même temps reste toujours présent.

Côté admin toutefois, il y a une nouveauté qui permet plus ou moins de pallier au souci précédent : il est en effet possible pour l'admin Moodle ou le DPO de lancer lui-même une demande d'export de données au nom de quelqu'un. Cela permet de ne pas avoir à cocher la case "Contacter le délégué à la protection des données" dans l'admin, qui fait justement apparaître le lien pour faire une demande d'export.

Reste le cas de l'export des données proprement dit...
Sur ce point, l'interface d'admin permet à présent donne à présent la possibilité d'inclure (ou pas) les journaux lors de l'exportation (exportlog). Il faudrait que je fasse un comparatif entre deux exports avec ou sans cette fonction, mais en tout cas, en l'excluant, le cron a bien moins de souci lorsqu'il s'agit d'attaquer la table des logs.

Par contre, à présent, mon cron bute sur la récupération des notes (Traitement de core_grades). Ce n'est qu'en relançant manuellement le cron à 3 reprises que mon archive s'est enfin finalisée. Sur ce point, j'ai d'ailleurs été étonné du temps de travail, alors que ce n'est clairement pas le pire système de table de Moodle (loin derrière les 28 Go de logstore_standard_log !).

Lorsque je regarde le poids de mes tables, celles qui dépassent les 1 Go sont :

  • la table des logs (mdl_logstore_standard_log) ;
  • la table de l'historique des notes (mdl_grade_grades_history) ;
  • les tables utilisées pour les tentatives de questions dans les quiz (mdl_question_attempts, mdl_question_attempts_steps, mdl_question_attempt_step_data).
Et comme par hasard, les trois process sur lesquels la génération de l'archive a buté chez moi sont :
  • Traitement de mod_quiz : ce process va récupérer toutes les données relatives aux quiz, réponses aux questions, points obtenus, numéros de tentatives etc. Ce traitement a duré environ 2 minutes ;
  • Traitement de tool_log : la récupération et le traitement de tous les logs, mais sur ce point, la nouvelle amélioration pour exclure certaines données est salutaire. Il s'agissait de mon point de blocage, mais à présent il a pu être traité en environ 5 minutes.
  • Traitement de core_grades : la récupération des notes est devenu ma nouvelle bête noire...
Mon premier message n'avait pas eu beaucoup d'écho, aussi je serai très intéressé de savoir si, depuis l'arrivée du RGPD, certains d'entre vous avaient été confronté à cette fonctionnalité d'export des données personnelles.

Olivier
Moyenne des évaluations Utile (2)
En réponse à Olivier Valentin

Re: Export de données et performances serveur

par Patrick Lemaire,
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Olivier,

Je me glisse dans ton fil de discussion même si je n'en suis pas encore au même stade (toujours en 3.1) mais tes interrogations et constats sont inquiétants.

La table mdl_logstore_standard_log est probablement un nœud critique sur lequel repose de plus en plus de fonctionnalités (Learning analytics par exemple). Je ne sais pas si MoodleHQ pense à faire quelque chose sur ce point. Pour des gros Moodle, cette table devient vite obèse.

As-tu songé à faire un retour via le Tracker ?

A bientôt,
Patrick

En réponse à Patrick Lemaire

Re: Export de données et performances serveur

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles

Bonjour Patrick,

comment ça, tu n'es pas en conformité RGPD ?? :D

Pour le moment, je n'ai fait strictement aucun retour car j'attendais d'avoir quelques avis de la communauté pour voir si d'autres rencontraient ce souci ou si tout se passait bien. Le fait par exemple de ne pas avoir de points de comparaison me laissait penser que les performances serveur étaient en cause. Mais à ce jour, cette discussion n'a pas eu d'autres retours.

L'obésité de mdl_logstore_standard_log est effectivement un point noir. Nous ne conservons ici que les logs sur un an et demi, la table pèse tout de même 28 Go (non déportée de plus) ! Il est clair que son interrogation pose souci, même si Moodle HQ a rajouté la fonctionnalité permettant d'exclure une partie des logs de l'export, ce qui est clairement appréciable. Si les logs étaient mon point de blocage avant, ça ne l'est plus aujourd'hui.

Le véritable problème, selon moi, tient actuellement plus du fonctionnement de la récupération, mais aussi au nombre d'éléments concernés. L'impossibilité de faire la circulation entre les demandes de données (c'est-à-dire de déclencher qui on veut quand on veut) est déjà effrayant, mais contournable.
Après, la récupération est énorme : chez nous, ce sont pas moins de 520 process de récupération qui se lancent !! C'est en cela qu'il est intéressant de mettre le nez dans ce module : les données personnelles potentielles sont partout, depuis le dépôt de devoir et les quiz jusqu'aux paramétrages des blocs, en passant par la messagerie interne, l'appartenance aux cohortes et les notes.

On est bien d'accord que sur certains aspects, Moodle passe en quelques millisecondes. Mais lorsqu'il s'agit d'attaquer les gros morceaux cités dans mon message précédent (logs, quiz et notes), ça prend une autre tournure. L'augmentation du délai de timeout du serveur peut être une piste, mais tout le monde peut-il modifier cette durée, et est-ce seulement souhaitable ??

A nouveau, sans partage d'expériences, il est difficile de dire si c'est une configuration locale qui est à l'origine du problème ou s'il s'agit d'un souci à faire remonter dans le tracker...

Olivier

En réponse à Olivier Valentin

Re: Export de données et performances serveur

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour Olivier,

Je dirai qu'ouvrir une demande dans le traqueur permet au moins de "marquer les choses", et éventuellement pousser d'autres personnes à se poser des questions.

Et si tu prends la peine de préciser très clairement ton environnement serveur (processeurs, mémoire...) ainsi que les paramétrages (limites PHP et BDD) et le dimensionnement de ta plateforme (nombre d'utilisateurs, de cours, de catégories, taille de la table de log...), ça donne déjà quelques bons points de comparaison.

Séverin

En réponse à Séverin Terrier

Re: Export de données et performances serveur

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Séverin > merci pour tes précisions ! Je vais aller voir comment sont rédigés les messages dans le tracker afin d'être le plus complet possible

De notre coté, notre serveur tourne sous Apache.

Processeurs :  4-vCPU 2.4Ghz de Xeon E5-2650
RAM : 20 Go

limites PHP et BDD : qu'entends-tu exactement par là ? On évoquait les éventuels timeout, c'est de cela qu'il s'agit ? Est-ce qu'on peut trouver toutes ces infos dans les infos serveur et PHP disponible dans la page Infos PHP dans la catégorie "Serveur" de l'admin ?

Olivier

En réponse à Olivier Valentin

Re: Export de données et performances serveur

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Je pensais effectivement plutôt aux fichiers php.ini et my.cnf, qui définissent les valeurs mémoire maximales, la mémoire allouée à différentes tâches et leur répartition, l'utilisation éventuelle d'OPCache, bref, tout ce qui peut toucher aux performances (et aux limites) du serveur.

Et la taille utilisée par la table de log, afin d'avoir une bonne idée du dimensionnement.

Séverin

Moyenne des évaluations Utile (1)
En réponse à Olivier Valentin

Re: Export de données et performances serveur

par Sébastien Mehr,
Avatar Développeurs Avatar Testeurs

Bonjour,

Si tu utilises une base de données MySQL/MariaDB, il y a un petit outil d'outil d'audit bien pratique :

https://github.com/major/MySQLTuner-perl

à l'issue de son exécution, le script fourni pas mal de pistes pour affiner la configuration de la base de données. Peut-être que les optimisations proposées te permettront de gagner en performance sur cet export.


Seb

Moyenne des évaluations Utile (3)
En réponse à Sébastien Mehr

Re: Export de données et performances serveur

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles

Séverin / Sébastien > c'est là que se trouve ma limite d'ingénieur pédagogique, je n'ai pas directement accès à tous ces outils, informations et fichiers sur le serveur, qui est géré par notre DSI... sourire

Niveau configuration, mon collègue m'a simplement dit qu'il avait passé notre serveur de test sous NGinx, suivant certaines préconisations de Moodle, pour améliorer certaines performances. Difficile de juger du résultat, notre serveur de test n'ayant qu'un quart de la puissance de notre prod !

Je vais déjà essayer de rédiger qque chose dans le tracker, mais si jamais j'ai un retour, ça sent les aller-retours d'information... et va y en avoir ! sourire

En tout cas, merci à tous pour vos réponses.

Olivier