La mesure est effectuée sur l'environnement de qualification. Les caractéristiques de cet environnement sont :

• serveur : ADVANCE-2 - Intel Xeon-E 2136 - 32GB DDR4 ECC 2666MHz - 2x HDD SATA 4TB Datacenter Class + 2x SSD NVMe 500GB Enterprise Class Soft RAID
• os : Linux debian 9.4 stretch
• CPU : Intel Xeon E-2136

Les mesures sont effectuée sur un serveur de qualification marginalement chargé par des tâches annexes. Les deux applications (boardz et moodle) sont sur le même serveur. Le tir CURL s'effectue sur l'IP publique de Moodle à partir du Boardz. Il peut bénéficier d'un facteur améliorant en étant situé sur la même machine, sans traversée d'équipements réseau externes.

• Capture des gaptimes, par capture des temps microtime() du système.
• Capture des consommations mémoire (visibles depuis PHP).

La classe \`boardz\utils\PerformanceMonitor regroupe l'ensemble des implémentations des outillages de mesure de la performance de fonctionnement du moteur BoardZ version 2.

Capture un temps dans la piste dédiée à la mesure $purpose

Mesure une vitesse instantanée (en contexte) de fonctionnement par division du dernier intervalle de temps par le nombre d'items traités dans l'intervalle.

La mesure adresse la vitesse nominale de traitement des logs d'une instance Moodle locale, dans un cycle de 5000 logs par phase et 10 secondes de “refroidissement” entre phases. La mesure adresse le temps d'intégration des enregistrements de logs, hors temps de réponse du service Web Moodle invoqué.

• vitesses mesurées : entre 250 et 360 logs traités /seconde soit entre 9M et 1,296M enregistrements par heure.

Boardz2 est conçu pour être :

1. multitenant
2. scalable horizontalement (nombre de plates-formes suivies)
3. scalable verticalement (quantité de données traitées)

A terme :

1. multiapplication

L'architecture interne de boardz permet la réunion de plusieurs bases de mesure indépendantes pour des “sites” indépendants dans la même base de données. Les fichiers de configuration permettent de définir les instances objets qui servent chaque site individuellement.

Les processus d'alimentation et de calcul continu des mesures peuvent être lancés chacun comme un processus unique, balayant successivement les différents tenants, ou peuvent également être invoqués contingentés à un site, ou parfois même un “objet” d'alimentation unique. Ceci permet de mieux contrôler une mise en oeuvre parallélisée de l'effort d'alimentation ou de calcul sur une plate-forme de grande volumétrie.

Chaque site a sa propre définition et son propre espace indexé d'enregistrements dans les tables du Boardz2. Cependant, plusieurs bases de données Boardz et plusieurs “installations physiques” du Boardz2 sont possibles sur une machine physique (ou une VM). Cependant, dans le cas d'installations “séparées”, les données statistiques ne pourront pas être consolidées en multisite.

Le BoardZ2 est un ETR (Extract, Transform and Report) organisé par “processus” autour d'un modèle de stockage de données en base de données. Les différents processus (synchrones réguliers pour les alimentations et mesures calculées, asynchrone pour les consultations de résultats) sont techniquement indépendants les uns des autres (même s'il peuvent être “ordonnancés” par une “dernière date de donnée disponible”). Ainsi il est possible de répartir sur des systèmes ou processeurs différents :

1. les diverses tâches d'alimentation ou de synchronisation de données. (E)
2. les tâches de calcul sur les mesures et les “transformées de données” (T)
3. les tâches d'assemblage et de construction de vues et de rapports (R)

A plus long terme :

1. des tâches de production et de distribution documentaire
2. des tâches d'alertes sur les indicateurs et données.

La répartition de ces différentes tâches de calcul sur des unités système différentes permet une certaine montée en puissance et une répartition de l'effort de calcul “PHP” du boardz.

En l'état du projet, la scalabilité verticale du stockage de données lui-même (base de données Boardz) n'est pas encore évaluée. Il est possible cependant de dévoiler quelques pistes plausibles d'architecture pour adresser cette scalabilité :

Boardz2 stocke quatre types de données :

• Les données de configuration internes : elles décrivent les objets du Boardz et leur assemblage. Ces données sont statiques en cours d'exploitation.
• Les données de “modèle” ou de référence“ : provenant des applicatifs, ces données sont relativement statiques en cours d'exploitation, même si elles doivent être régulièrement resynchronisées à partir des applicatifs qu''elles décrivent.
• Les données “captées”, soit des alimentations (feeders), soit à partir de mesures directes (measurement) et de leurs source de données (datasources). Ces données sont dynamiques, elles arrivent en flux continu à partir des applicatifs en exploitation.
• Les données “transformées”, issues de calculs sur les mesures ou les indicateurs, et constituant des “caches” locaux de valeurs calculées intermédiaires, directement consultables par les vues et les rapports. Ces données sont dynamiques et “suivent” (data-tracking) la réception des données 'captées”.

La gestion de la croissance des tailles de stockages pour ces données peut être adressée :

• par segmentation du stockage pour des instances séparées (réduisant la taille de stockage globale du “tablespace” pour chaque type de données)
• par répartition des deux derniers types de données (alimentation et données transformées) dans deux unités de bases de données distinctes.

Dans le premier cas, l'avantage vient de la réduction de l'arité des index dans chaque table, accélérant le calcul des sélections de données, mais en rendant difficile la consolidation de données. Dans le deuxième cas, la consolidation de données reste plus simple et accessible, mais les temps de calcul liés à la taille des index ne sera pas globalement améliorée.

Revenir au sommaire