Propositions concernant les blocages / ralentissements des transactions lors de gros évènements

Bonjour,

Lors de ces RML14, nous avons expérimenté des ralentissements lors de l’envoi des transactions et/ou de la consultation des comptes. Fort heureusement, l’équipe organisatrice avait affiché les adresses de noeuds où se connecter, et globalement ça s’est bien passé.

Je crois que lors des RML13, certaines transactions avaient même été perdues.

Ceci est principalement dû au fait que g1.duniter.org est surchargé, car par défaut sur Cesium. Le réseau wifi a aussi pu montrer des faiblesses à certains moments.

Comme les prochaines RML sont à Paris, et qu’il risque d’y avoir encore plus de monde et de transactions, je jette quelques idées d’amélioration. Je ne sais pas si tout est réalisable.

Affichage

Afficher, en plus d’une liste de noeuds disponibles, des captures d’écran Cesium montrant comment changer de noeud. Avoir de telles affiches dans toutes les salles.

Noeud spécifique pour les RML

Installer un noeud miroir spécialement pour les RML, sur un serveur de haute disponibilité. L’installer quelques jours auparavant et lui synchroniser ses piscines manuellement à plusieurs reprises pour que les certifs en attentes soient là et que les gens ne s’affolent pas. Eteindre ce noeud quelques heures après. Evidemment, afficher ce noeud en premier dans la liste des noeuds disponibles.

Réseau

Avoir un noeud miroir installé sur un ordinateur un peu costaud (je ne sais pas quelle configuration ça implique) directement sur le réseau local des RML.

Avec une gestion DNS au niveau local (par exemple en lui donnant le nom monnaie.libre), ça permettrait de répondre aux requêtes des clients sans surcharger la connexion internet sortante.

Indiquer ce noeud sur la liste des noeuds dispo, avec la note « entrer l’adresse manuellement ». et/ou mettre directement son IP locale.

Hacker Duniter

Je ne sais pas si c’est possible, mais il me semble qu’un des souci rencontrés a pu être un bourrage des piscines. D’où une question : lorsque la mempool d’un noeud est pleine, transmet-il quand même les tx au reste du réseau ?

Il existe la variable SANDBOX_SIZE_TRANSACTIONS, qu’on pourrait augmenter sur le noeud spécifique aux RML avant compilation. Doubler ou tripler la taille peut-il poser problème ?


J’ai eu ces idées ce weekend, mais je ne sais pas ce qui est bon et ce qui est à jeter. Les remarques sont bienvenues !

5 J'aimes

Globalement il y a un problème de disponibilité d’API client (BMA, future GVA).
Elles se font rares sur le réseau pour le besoin actuel et quand il y en a elles sont surchargées du fait qu’il y en a peu sur le réseau.
Je pense que c’est un problème global, pas lié à la RML, juste que le besoin se fait plus sentir à ce moment-là.
C’est donc un appel aux administrateurs de nœud à rendre accessible leur point d’accès BMA pour décentraliser et renforcer la bête.

Je me suis rendu compte que mon nœud était assez sollicité. Je voudrais l’utiliser en usage perso, à savoir uniquement en réseau local et plus le partager sur Internet tout entier. Mais, c’est pas ce que je propose de faire plus haut.
Plus la charge sera faible par nœud, plus on aura envie d’ouvrir des points d’accès.
Plus la charge sera élevée, plus on aura de nœud sursollicité qu’on aura envie de ne plus partager, et on se retrouvera avec des points d’accès quasiment rares.

Je sais pas comment encourager les admins de nœuds à ouvrir leurs BMA sur le net. Des Ğ1 ?

2 J'aimes

Un tuto pour noob, avec en plus des sections spécifiques par FAI (config dns, d’ouverture de ports, etc, pour freebox, livebox, etc). Je voulais m’y lancer mais j’ai préféré espagnoliser.

Après, il y a aussi la possibilité de monter sur g1.duniter.fr de la répartition de charge tant que le client Cesium a une seule conf par défaut qui genere ce goulet.

En attendant, Faudrait publier tout public une liste actualisée des nœuds avec les bonnes api ouvertes.

Moi qui montait mon noeud en dilettante, je me retrouvait souvent à zapper l’ouverture des ports. L’upnp fonctionne vraiment ?

1 J'aime

Oui à condition que l’upnp soit activé sur la box de l’utilisateur final, mais BMA est désactivé par défaut :sweat_smile:

Bonne idée, c’est très facile et assez peu coûteux à réaliser avec DigitalOcean, on peut installer une bête de course pour quelques jours et sans se ruiner en UNL.

Pour se donner un ordre d’idée, un serveur 32 GB RAM / 16 CPUs coûterait environ 52 UNL sur 5 jours complets (de quoi couvrir les RML, ainsi qu’une période de synchronisation des piscines). M’est avis que ce serveur est toutefois déjà overkill.

Aussi le nœud g1.duniter.org a pour principal problème de partager le serveur avec d’autres logiciels, mais aussi c’est un Kimsufi. Pas le top en termes de performances.

Un module Duniter

Enfin, ce qui sollicite fortement le serveur c’est la consultation des sources de monnaie. Je vais peut-être voir pour intégrer un module Duniter qui s’occuperait de gérer cette consultation via un nœud ElasticSearch plutôt que le nœud Duniter lui-même, ce qui améliorerait sensiblement les performances AMHA.

À noter que je prêche depuis longtemps cette solution qui consiste à sortir tout ce qui est consultation client dans un module à part pour ne pas impacter le cœur de problématiques qui ne devraient pas lui incomber. Là je parle des sources de monnaie, mais c’est valable pour tout document Duniter (identités, certifications, adhésions, blocs, …).

Ces solutions peuvent se combiner.

2 J'aimes