Documentation Moodle ActiveProLearn

APL réalise des tests de charge sur vos installations moodle pour déterminer la qualité de l'infrastructure, sa puissance effective, ses seuils de rupture, ses coefficients APDEX).

Dans certains cas les tests de charge permettent aussi de détecter des configurations de moodle qui posent un problème de scalabilité du fait de certains choix applicatifs.

1. Si vous désirez faire tester votre implantation, vous devrez préparer une copie de votre plate-forme sur un domaine de test (par exemple, si votre moodle tourne sous https://mon.moodle.com, vous pourrez par exemple préparer une instance https://mon-test.moodle.com).

Cette instance peut être vide où contenir toute ou partie de vos données de production. Avec les données de production, les temps de réaction des pages seront plus proche de la réalité du ressenti utilisateur. Sans les données de production, nous mesurons une plate-forme idéale fraîchement installée).

2. Vous tenez à notre disposition un compte administrateur.

3. Vous organisez un créneau où les tests pourront se passer. Il ne doit pas y avoir d'autre activité sur le serveur pendant les tests de charge, où les résultats seront faussés par rapport à la capacité réelle de votre installation. De plus les tests de charge altéreraient très fortement les autres usages. Idéalement, si vous pouvez dérouter le flux de votre domaine principal pendant les tirs, ce sera une assurance de ne pas altérer la mesure.

En général, une campagne de mesure s'effectue avant la mise en production d'une installation. Mais ce n'est pas toujours possible.

4. Vous effectuez une sauvegarde complète de vos données de production. En général, même si les tests de charge ont pour but de trouver le point de rupture de votre installation, et ce potentiellement en mettant “à genoux” votre infrastructure, Les données de production mises en sommeil ne sont pas touchées par les tests. Les données de test seront effacées du serveur suite à la campagne. Il est néanmoins prudent d'effectuer une sauvegarde complète préalable au cas où une surcharge viendrait par exemple corrompre un stockage de base de données.

5. Pour une qualification complète de votre installation, nous avons besoin de mesurer, en même temps que les réponses applicatives, l'état technique de vos infrastructures (machines). si vous disposez d'un monitoring déjà installé, nous aurons besoin d'un accès aux graphes système. Sinon, nous pouvons nous charger de mettre votre installation sous surveillance technique (sondes) pendant la durée de la prestation.

Nous travaillons essentiellement avec un jeu de sondes Nagios, sous OS Linux. la mise en place de monitoring sous Windows/NSCP est possible sur devis.

Apl va dérouler pour vous :

• Mise en place le la supervision active de vos infrastructures.
• Mise en place d'un jeu d'utilisateurs de test sur votre instance de test
• Configuration de notre plate-forme de tir. Nous tirons en principe à partir d'un serveur installé chez notre hébergeur (OVH) qui correspond à un usage “extérieur” à votre plate-forme. Si vous êtes hébergés également chez OVH, il est possible que le test soit un peu plus optimiste qu'une réalité d'usage à partir de sources internet hétérogènes. Nous pouvons vous proposer de mettre en oeuvre des mesures complémentaires à partir d'un autre hébergeur pour ne pas bénéficier du taux de transfert avantageux d'OVH vers OVH.
• Tir des tests, en volumétrie progressive, jusqu'à la consigne de volumétrie demandée. Si nous détectons une rupture de votre infrastructure en deça de l'objectif de charge, nous arrêtons les tests et qualifions les causes possibles.
• Récolte, compilation des mesures, rapports de test et note d'interprétation.
• Suppression des données de test.

Le principe général d'un test de charge est la simulation d'une population arrivant sur le service et naviguant selon un scénario défini à l'avance pour le test. Un jeu d'utilisateurs factice est installé sur moodle, permettant à l'outil de charge de se connecter en lieu et place des utilisateurs et simuler les clics et les temps d'attente entre les différentes sollicitations.

Pour certains tests, un préchauffage peut être nécessaire. Cette étape consiste à lancer une première charge permettant de positionner certaines données en cache avant que le vrai test ne commence.

Les temps d'attente sont variables dans le test, entre chaque requête, entre deux valeurs min et max. Nous avons calibré ces temps d'attente à partir de traces de temps réelles sur des plates-forme en production. Ils sont donc représentatifs d'un comportement plausible de vrais utilisateurs.

La mesure principale d'un test de charge est le temps de réception de la réponse. En principe, lorsqu'une installation “prend de la charge”, le temps de réponse global de la plate-forme peut se dégrader. Le test de charge a pour fonction essentielle de mesurer l'impression utilisateur et non des performances techniques du logiciel.

Les taux d'erreurs sont aussi un résultat important d'un test de charge. Il y a deux types d'erreurs à distinguer :

• Les erreurs techniques (500, 502, 503) dues au dépassement de limites physiques de l'installation
• Les erreurs dus à des valeurs de seuils de temps du test lui-même (timeouts admissibles).

Dans une application complexe, il est tout à fait normal que certaines requêtes mettent plus (parfois beaucoup plus) de temps que d'autre. L'injonction de dire “Toutes les pages doivent s'afficher en moins de 2 secondes” que l'on trouve dans certains cahiers des charges ne correspond en rien à la réalité de fonctionnement des applications.

En lieu et place de ce type d'assertion, on utilise de manière plus positive la notion de “percentile”.

Les percentiles mesurent le temps de réponse moyen d'une proportion de pages de manière à pouvoir dire :

 X pour cent des pages ont pu répondre en moins de Y secondes

Les percentiles couramment utilisés sont le percentile 90, 95 et 99 (exprimés en %). Un percentile 99 à moins de 500 milliseconde est le signe d'une application très bien réglée avec un hébergement (et une complexité algorithmique) optimums.

L'APDEX est un indice qui calcule le taux de satisfaction des utilisateurs face à une application plus ou moins complexe et dont les temps de réponse des différentes pages peut fortement varier :

Tous nos tests de charge ont été qualifiés et révisés par Ubik Ingénierie, SSII spécialiste en France des outils de test de charge.

Nos tests de charge utilisent en partie les tests produits par l'administration Moodle, enrichis et recadrés pour simuler des situations pédagogiques réalistes. Les 5 types de test que nous lançons peuvent varier en volumétrie, afin de trouver progressivement le point de rupture.

• Test en rampe sur une seule session (navigation type)
• Test en rampe avec rotation de sessions (navigation type)
• Test en impulsion
• Test de soumission de devoir/mémoire
• Test d'examen (quiz qcm) en ligne

Ce test est inspiré du scénario standard de moodle :

• Connexion d'un certain nombre d'utilisateurs
• Chaque utilisateur se lance dans une session continue d'utilisation (vue du cours, participation aux forums) jusqu'à la fin de la durée du test

Objectif du test : mettre en charge “continue et stabilisée” Moodle pendant une durée suffisamment grande pour :

• examiner la linéarité ou non linéarité de la réponse de l'infrastructure en fonction de la charge
• détecter le point de rupture (passage de la réponse linéaire à la réponse chaotique)
• détecter d'éventuelles dérives (fuites de mémoire, algorithmes accumulatifs) de scalabilité dans la durée.

Idem que le précédent, mais les utilisateurs simulés se déconnectent au bout d'un certain temps pour être réengagés sur une nouvelle session avec un autre utilisateur. Ce test est le plus proche de la version standard du test de charge moodle.

Il est conçu pour mesurer le temps de résilience d'une installation devant une arrivée brutale et massive de requêtes. Le temps nécessaire pour absorber toutes les demandes arrivées en un temps très court permettra de déterminer le comportement de la plate-forme dans des situations pédagogiques critiques comme des activités quasi-synchrones de la population.

Scénario :

• Les utilisateurs arrivent massivement sur une période très courte (quelques minutes au plus) pour effectuer une série de boucles de navigation simples avant de ressortir et quitter la plate-forme.

Objectif du test :

• Mesurer la réponse “impulsionnelle” de la plate-forme
• Savoir en combien de temps un volume de population peut être servi sur un cas d'usage simple (par exemple, un amphi de 800 places doit répondre à un sondage au top donné).

Revenir au catalogue des services - Aller à l'index des plugins - Guide de démarrage/FAQ sur Moodle