BoardZ Moodle Stat Project

Les fonctions de calcul de données statistiques à partir d'enregistrements de bases de données peuvent aujourd'hui être réalisés selon une grande quantité d'architectures techniques tant les langages et les briques logicielles ont évoluées et maturées.

On doit distinguer cependant encore 3 grandes familles d'implémentation :

• Les implémentations scriptées (non compilées) incluant Php, Python, Ruby, NodeJS (Javascript server), Perl, etc.
• Les implémentations compilées comme Java ou C#.
• Les implémentations compilées haute performance, comme le C ou le C++.

Le choix majeur d'une technologie de réalisation d'un projet dépend finalement d'une équation assez simple : Il repose essentiellement sur le rapport entre l'interface et l'interaction utilisateur d'une part, et le masse de calcul ou d'automatisation d'autre part. Les langages scriptés sont très habiles à produire de l'interface et des interactions utilisateur à moindre coût, flexible, agile, permettant des modifications à mise en oeuvre quasi immédiate, ou du moins simple, mais sont d'une performance calculatoire et algorithmique assez faible. En revanche les langages compilés et le mode de conception en serveur persistant rend assez coûteux le travail de l'interface, mais au contraire favorise la vitesse et la quantité de calcul.

Le fonctionnement de BoardZ suppose 3 principales tâches dans son fonctionnement continu :

• Recevoir les données
• Compiler les données sources et les transformer (dimensionnalisation, agrégation, distribution)
• Restituer les données aux demandeurs

Nous négligeons ici les tâches exceptionnelles de gestion du serveur et de maintenance de données.

Tout, dans la problématique de tenue à la volumétrie, va être lié à l'architecture des traitements et des modèles de données sur lesquels ils vont s'appuyer. 3 paramètres influent sur la volumétrie de traitement dans le serveur :

1. La volumétrie d'entrée, de manière non triviale, car l'augmentation de la volumétrie d'entrée n'entraine pas forcément un accroissement équivalent de la quantité de traitement. Dans le cas de BoardZ, on pourra associer ce critère à la “taille du moodle” c'est à dire la somme du nombre de ses contextes multiplié par la densité d'usage de la plate-forme.
2. La fréquence du traitement : Dans une application multiutilisateur, il est fréquent que plusieurs utilisateurs distincts demandent le même calcul. Plus ils sont nombreux et plus ils le demandent, plus ce calcul sera exécuté et réexécuté souvent. C'est ici tout l'intérêt des stratégies de “cache” qui essaient précisément de stocker des résultats précalculés pour s'économiser ce recalcul. Dans le cas de BoardZ, on peut fonctionnellement associer ce critère au nombre d'indicateurs demandés et la fréquence d'affichage de ces indicateurs.
3. La complexité du traitement : avec les mêmes données sources, selon la formule de calcul qui est demandée, le parcours des données peut être multiple, voire même polynomial. Le travail sur la complexité des algorithmes permet de réduire cette complexité dans une mesure importante, mais aussi au prix de mises en oeuvres plus complexes à développer. Ramené à BoardZ, ce critère sera associé à la définition même des indicateurs, selon qu'il sont scalaires, vectoriels, comparatifs, temporels, etc et la mesure demandée sur ces indicateurs.

Avec ces données en poche nous pouvons analyser les différentes phases de traitement du service :

La réception des données est peu concernée par une question de performance, car le traitement est assez trivial : recevoir une (ou plusieurs) entrée(s) d'événement de moodle et la poser dans un tampon d'attente à destination de la tâche de traitement. L'objectif de cette tâche est d^être toujours disponible pour un appel de “push” et de ne jamais faire attendre le serveur Moodle. Le raffinement de la conception déterminera dans quelle mesure des pré-traitements peuvent être effectués lors de la réception, mais ils ne seront jamais lourds. La fréquence de ce traitement pourrait poser problème s'il fallait traiter une requête par événement sortant de Moodle. Deux décisions architecturales permettent de maîtriser ce point : le fait que l'agent émetteur des événements (plugin de journalisation) ait lui-même plus ou moins filtré le flux des événements non pertinents “au départ” de moodle, mais aussi la capacité à bufferiser un certain nombre d'événements et à les envoyer par paquet.

Dans tous les cas de figure, ce type de tâche pourrait très bien être confiée à un moteur Web simple rapide (en mode événement de type apache “event” + php ou nginx + python par exemple)

La fonction calcul déclenche le premier et le troisième critère de performance : la volumétrie et la complexité. La fonction de calcul reçoit des données sources (événements) et les compile dans des modèles de données statistiques. En général, une fois la donnée consommée et intégrée, le moteur n'y revient pas dessus (sauf dans le cas d'une reprise de données antérieure, mais ceci est un acte de maintenance de données, pas de fonctionnement normal). Cependant, cette fonction de calcul ne produit pas d'interaction utilisateur. Elle doit de plus être particulièrement optimisée pour laisser la puissance de l'infrastructure au service de la restitution et de l'appel des vues et tableaux de bord.

POINT D'ALERTE :

L'avantage du langage compilé dans cette phase est évident.

Le traitement de rendu des données doit encore être divisé en deux phases :

• La préparation des données
• Le formatage des données

La préparation des données sélectionne les données issus du modèle de stockage (le cube statistique) et calcule les variables utilisées pour le rendu. Plus le modèle de rendu est sophistiqué et intègre par exemple des fonctions interactives de manipulation de la vue, plus cette phase de préparation peut être complexe et lourde. La complexité de la préparation dépend également de la puissance du stockage statistique. Plus ce dernier est capable de stocker des valeurs proches des sémantiques du rendu, moins la préparation est couteuse pour produire la vue. Plus le stockage est brut, plus il faudra calculer lors de la construction du rendu.

Dans une architecture où le rendu ne serait qu'une action de remplissage d'un “format” de sortie, cette phase pourrait être confiée à une technologie scriptée. Dans la réalité, il y aura partage probable de l'effort de calcul entre le moteur de calcul et la fonction de rendu. Les technologies compilées sont également gagnantes en général surtout lorsqu'elles s'appuient sur des persistances de données en mémoire.

en dépit des qualités intrinsèques des langages compilés pour la performances de fonctions de calcul complexes et de manipulation de structures de données, la décision finale d'orienter le projet vers une technologie “full PHP” a été prise pour les raisons suivantes :

• Des gains en performance significatifs uniquement à très haute charge, dont l'absence peut être compensé par d'autres techniques (augmentation physique des infras support, clusterisation et parallélisation de calcul, etc).
• L'évolution du PHP vers un modèle objet de plus en plus complet, incluant les principes fondamentaux de Réflexion et de MultiThreading (sous certaines conditions).
• Une plus grande disponibilité des compétences de développement sur ces langages
• Le coût moindre des compétences de programmation dans les environnements “bien connus” de scripting web.

Revenir au sommaire de la conception - Revenir au sommaire général