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

Nodes Duniter-v1
, , , ,
1

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 Likes
2

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 ?

3 Likes
3

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 Like
4

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

5

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.

3 Likes
6

Il reste le cas du village qui n’a pas accès à internet, ou pour les personnes qui n’aiment pas les ordinateurs et se contentent d’un téléphone. Une part non négligeable de la population… Une population qui en plus est très avide de monnaie libre parce que dans des trous marqués par l’absence de monnaie dette.

Pour ceux là, et les autres, on est dans la capacité (avec @poka et ceux qui voudront se joindre) de préparer des BOX G1sms qui donnent accès aux G1wallets par SMS, permet d’imprimer des G1Billets (Flyer, Portefeuille ou Billet en prêt) et permet “d’animer le groupe” (canal push) par SMS et EMAIL :wink:

Bref, une solution pour tous, sans trop de mégastructure dans le Cloud (privé)… Et qui a la propriété de pouvoir se transformer en Cloud IPFS lui-même :wink: G1sms+ devient un robot transactionnel multicanal interconnecté par essaims IPFS au travers de frontières.

G1sms _IPFS_Swarms
G1sms _IPFS_Swarms1587×1046 274 KB

Je cherche à connecter un “Réseau Social” à cette méta-structure… ScuttleBot semble un bon candidat… Mais je me casse les doigts et les neurones sur l’enchevêtrement des clefs dans cette crypto jungle. Il va me falloir du temps et de l’aide pour que je me bricole un trousseau ala “passe-partout” pour coudre tout ça ensemble.

1 Like
7

Ouep. En attendant, duniter-g1.p2p.legal est dans une KVM 4Go de ram, 2 CPU, SSD, que je peux augmenter à 6CPU, 15Go de ram à chaud en un clic au besoin. Je n’avais pas pensé à le faire pendant les RML tient.

2 Likes
8

Salut à tous,
Je n’ai pas l’impression que ce soit un problème de performance des machines, je m’explique.

Je participe à la plupart des évènements « de masse » qui ont eu lieu sur Toulouse depuis un peu plus de 2 ans et j’ai effectivement constaté le problème de « ralentissement ».

Comme je ne suis pas un expert de duniter, j’ai pris le parti d’ expérimenter une sort de « spooler » de paiement qu’on remplit et qui passe les paiements quand il peut en s’appuyant sur silkaj.

J’ai fait un premier test en passant d’un coup 250 paiements de 1Ḡ1 d’un compte source vers un compte de destination, en environs 10 à 15 minutes, tous les paiements sont passés.

Nous avons fait ensuite à plusieurs un test avec 4 comptes différents en échangeant quelques paiements à vitesse humaine (une dizaine d’échanges en 15 minutes) toujours en utilisant le même spooler de paiement (qui est sur un serveur et qui a une ip unique) et là au bout de quelques échanges nous avons eu des erreurs notamment au moment de récupérer les balances des comptes (silkaj balance ).

Le point commun avec les évènements monnaie libre c’est qu’on s’est connectés avec plusieurs comptes de façon un peu intense depuis la meme ip (mon spooler ou la box dans le cas des gmarchés).

Du coup la question que je me pose est : est ce qu’il y aurait un mécanisme dans duniter qui détecterait un comportement de ce type comme étant suspect ?

Je précise que mon spooler tire au sort un noeud différent parmis une dizaine de noeud que j’ai identifiés comme stables et en fonction, et qu’à un moment la plupart des noeuds se mettent à avoir le même comportement.

Si ça peut aider à avancer sur cette question…

++

2 Likes
9

Il y a un mécanisme d’anti-spam sur le nombre de requêtes faites à partir de la même adresse IP.

10

du coup c’est ptet simplement ça qui bloque vu que pour les évènements tout le monde se connecte depuis la meme ip

11

…et potentiellement au même nœud Duniter.

12

Oui c’est probablement le mécanisme anti-DDOS de BMA qui est un peu trop strict

13

…ou que tout le monde centralise l’usage de la ou des mêmes API BMA.

C’est déjà ce que j’ai exprimé dans mon post plus haut (le second).
Il faut en plus que les utilisateurs utilisent un autre nœud que celui proposé par défaut par les clients.

Je vois pas comment mettre ça en place d’un point de vue client mono-nœud (point d’accès). Sakia répartie la charge réseau sur toutes les BMA, il ne devrait pas rencontrer trop de souci.

  • Mettre une liste en dur : petite liste restreinte de point d’accès qui devient obsolète si pas maintenu.
  • Après une trop grande utilisation du nœud par défaut, proposer à l’utilisateur de chercher un autre nœud pour éviter la centralisation. S’il n’est pas technique, il risque d’en prendre un qui n’est pas de confiance.

Ces propositions sont pas intéressantes. Pas simple à résoudre comme problématique.

1 Like
14

Dans mon cas ça load balance (en random) sur 8 à 10 nœuds différents en passant l’option -p différente à chaque requête à silkaj.

En fait dans mes tests j’ai pu passer 250 paiements sans problème tant que j’ai pas interrogé la balance des comptes.

C’est quand on commence à abuser des silkaj balance que ça semble se mettre en route, fred m’avait parlé déjà de ça sans vraiment savoir me dire s’il fallait l’attribuer à silkaj ou a duniter.

1 Like
15

Les commandes tx et balance font à peu près autant de requêtes. Elles récupèrent toutes les deux les sources (et les pending) pour calculer le solde du compte (émetteur dans le cas de tx) et plein d’autres requêtes pour la valeur du DU, le bloc courant…

La commande tx doit faire faire une pause dans le requêtage, car elle demande confirmation de l’émission du document. Sauf, si --yes est employé.

16

De mémoire je les passe avec un --yes.

Pour pas se focaliser sur la technique, je pense que le mecanisme d’anti-spam a du sens mais dans l’usage qui en est fait notamment sur les évènements, c’est effectivement problématique car on se retrouve de la part du public avec un problème de crédibilité (pour eux ça marche pas - diagnostic super rapide).

A priori monter un noeud duniter en local devrait permettre de ne pas déclencher le mécanisme d’antispam, puisque tout le monde va arriver avec des ip privées locales s’il est connecté au wifi. On pourrait eventuellement faire un fake dns local qui redirige les requetes vers les principaux noeuds duniter vers le local.

Dans un premier temps ça peut permettre de valider que c’est bien le soucis qu’on rencontre.

La question subsidiaire pas facile à trancher c’est le dimensionnement du noeud.

2 Likes
17

Dans ce cas, il est possible que le rapport technicien/non technicien ne soit pas assez grand pour accueillir suffisamment de non techniciens. Il est peut-être trop tôt.

18

Oui je comprend le problème c’est une quadrature du cercle difficile à résoudre ce rapport technicien/non techniciens

19

Bon du coup je vais essayer de voir si on peut utiliser un de mes serveurs pour le festig1, on remontera le trafic local dans un tunnel.

C’est quoi les recommandations actuelles en terme de version de duniter 1.7.19 ?

20

Il n’y a pas de recommandation. Il faut prendre la dernière « Release » en date : la 1.7.18 en l’occurrence.

1 Like