Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:design:technologychoices [2019/01/21 15:09]
admin [Le choix de Java (J2SE)]
+++ boardz:design:technologychoices [2022/10/06 10:34] (Version actuelle)
florence
@@ Ligne 1: / Ligne 1: @@
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
 ===== Options Technologiques =====
 ===== BoardZ : Version 2 =====
-==== Le choix de Java (J2SE) ====
+==== Le choix de PHP ====
 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.
@@ Ligne 28: / Ligne 29: @@
    - 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 :
+=== Réception des données ===
+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)
+=== Calculs sur les données ===
+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.
+=== Rendu des données ===
+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.
+==== Conclusion générale ====
+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.
+----
 [[:boardz:design|Revenir au sommaire de la conception]] - [[:start|Revenir au sommaire général]]

BoardZ Moodle Stat Project

Outils pour utilisateurs

Outils du site

Différences

Outils de la page