Duniter: performances de la synchronisation de la blockchain

Et je pense que c’est la BDD qui aujourd’hui ralenti les synchro via les accès disques. Ça permettrait sûrement de voir revenir des hébergeurs de noeuds qui ne peuvent plus le faire aujourd’hui (c’est mon cas en tout cas ^^)

Bref, entre ça et le cluster de pow, c’est prometteur cette oxydation.

1 Like

Sur la synchro je pense qu’il va y avoir une optimisation notable avec le protocole v13 puisque Duniter n’aura plus à gérer d’élagage des comptes < 1,00 Ğ1.

Pour la base de données, je ne suis pas sûr. LevelDB est quand même très rapide, par contre peut-être que l’utilisation de Rust plutôt que JS dans le code sollicité par la synchro augmentera les performances.

1 Like

Du coup je me suis plongé dans les options avancées de LevelDB et c’est vraiment pauvre en options, y a 3 fois rien (comparés aux plusieurs dizaines d’options de LMBD).
Plus embêtant, il n’existe pas d’équivalent a l’option NO_SYNC de LMDB qui permettrait de tout écrire en mémoire puis de sync sur le disque seulement a la fin du traitement, donc pas possible de tuner de ce côté-là :confused:

J’ai fait quelques tests en désactivant la compression et en augmentant l’option writeBufferSize (ce qui est censé rendre l’écriture plus rapide), j’ai bien une DB plus grosse (4,2 Go au lieu de 400Mo) et la conso mémoire qui explose (4,2 Go au lieu et 1,8 Go) mais aucun impact sur la durée du traitement (14 minutes dans les 2 cas sur mon poste de dev en SSD pci-express).

A noter que j’effectue tous mes tests en sync locale pour ne pas impacter les résultats par la partie “réseau”.

La seule explication que je vois est la suivante :

Quand on tune les perfs d’un process, c’est toujours le plus lent qui impose son rythme, je pense que le code de synchronisation de la blockchain est tellement lent par rapport à LevelDB que du coup les changements d’options de LevelDB n’ont aucun impact sur la durée du traitement.

Donc si on veut améliorer la sync je pense qu’il faut d’abord oxyder le code d’indexation et la couche DAL.

Ce qui est certain c’est qu’on a une grande marge de progression, je viens de retester la même sync (les 300000 premiers blocs de la G1) avec Dunitrust : cela a pris 30 secondes avec une conso mémoire max de 800Mo et la bdd finale ne fait que 335Mo (sans compression).

Ces résultats sont à relativiser avec le fait que Dunitrust n’indexe pas la balance des comptes, nous verrons avec DUBPv13 quel est l’impact de ce retrait sur la durée de la synchro de Duniter.

Notez toutefois que les perfs de Dunitrust ne pourront pas être atteintes sur Duniter, même après une oxydation du code de la synchro car :

  • Le format des index et la manière d’indexer n’est pas du tout la même. J’ai conçu les index de Dunitrust de manière à ce qu’ils soient rapides pour indexer un bloc, ce n’est pas le cas du tout dans Duniter. Ma priorité étant la stabilité de Duniter, je ne vais pas m’aventurer à refondre le format de ses index, pas à court terme en tout cas, donc les perfs ne pourront pas être équivalentes.
  • Il n’y a pas de wrapper Rust stable, complet et bien maintenu pour LevelDB, je serais donc obligé de passer par le module npm leveldown. En théorie Neon le permet, le code Rust peut appeler du code Node, en pratique je n’ai encore jamais testé. Mais même en supposant que ça fonctionna bien en pratique (ce que j’espère), le fait de passer par une couche Node Entre le code DAL oxydé et LevelDB induira forcément des pertes de perfs (je ne sais pas à quel point).

Bon c’est un peu tôt pour vous dire tout ça, mais ça vous permet de savoir que je réfléchis déjà a comment améliorer la sync de Duniter :slight_smile:

10 Likes

Cool !

J’ai finalement décidé cet été de forker le wrapper Rust pour LevelDb et de rajouter ce qui manquait pour Duniter, j’arrive désormais à lire l’intégralité de la base de donnée de Duniter depuis du code Rust :smiley:

Ce qui m’a permis de coder un explorateur de la DB de Duniter : Dex (Duniter DBs Explorer)

9 Likes