Merci @nicolas pour toutes ces infos.
nicolas Et sinon je me suis amusé à faire un petit script en repartant de la liste de tous les warnings :
J’ai un peu plus de mal à comprendre ce graphique. Je pense que l’absence d’en tête de colonne y est pour quelque chose. J’ai l’impression que la quatrième colonne c’est la première multipliée par la troisième. Est ce que ça serait un tri pour montrer quels salons auraient le plus d’impact sur le processeur du serveur ?
Je pense que c’est un sujet de fond qui mérite d’être discuté en réunion. Dans ce sens, je tente de faire une synthèse des questions que ça soulève.
Complexité
Les salons Matrix ont un indice de complexité. Plus il y a de comptes discutants dans un salon et plus il est ancien, plus la complexité du salon augmente.
En réduisant l’accès aux comptes Matrix CLUB1 à des salons au dessus d’une certaine complexité, on réduit fortement la charge du serveur en rendant inaccessible un nombre très faible de salons.
Questions que ça pose :
Est ce que l’on a envie de faire que les comptes Matrix du serveur soient limités par rapport à d’autres comptes créés sur d’autres serveurs ?
Un écosystème fédéré, comme Matrix, est d’autant plus complexe à appréhender que les règles peuvent différer sur chacun des serveurs qui y participent. En s’éloignant de la configuration « par défaut », on participe à sa complexification. (Ici il s’agît de la complexité de prise en main pour de nouveaux.elles utilisateurices)
Quel message serait affiché lorsque qu’un compte Matrix tenterai de joindre un salon trop complexe ?
Comment bien présenter un tel parti pris sur nos espaces Web (Wiki et documentation).
Point sur le serveur Matrix
Selon moi, le serveur Matrix doit être considéré différemment de tout les autres services CLUB1. Je pense que CLUB1 ne doit avoir aucun engagement vis à vis de son maintient, de ses performances et ouverture. C’est un peu le cas pour tout, mais là encore moins 🤣.
Je dis cela par rapport au fait que : le serveur n’est pas fait pour s’adapter à la quantité d’utilisateurice, mais c’est plutôt l’inverse. Cela est dû au fait du parti pris de départ d’avoir un serveur limité par des capacités physiques (harware). On dit qu’il ne peut pas « scaler » (changer d’échelle).
Hors, le serveur Matrix, avec ses inscriptions ouvertes, est une sorte d’absurdité, car il va lui, continuer de grandir à l’infini. Ce qui n’est pas gérable avec des ressources finies. Voilà pourquoi je pense qu’il faut considérer ce service comme une expérimentation.
Un aspect qui me rassure est le fait que, contrairement à de l’hébergement de sites web, ou par rapport à un forum, un outil de discussion instantané n’est pas dédié à de l’archivage, mais bien à gérer des échanges éphémères. Je pense que c’est une autre façon de légitimer le fait d’avoir moins de garantie sur ce service.
🐥 Problématique simplifiée
On en arrive au choix de ce que l’on préfère héberger. En gros : plus de sites web ou plus de conversations Matrix ? Grâce à la proposition de Nicolas, on a un peu plus de nuances possibles. Il est possible de réduire la partie Matrix, mais d’une façon spécifique (plus de comptes mais moins de conversations lourdes)
