J’aimerai améliorer les temps de réponse de /wot/requirements/:search dans l’API BMA.
J’ai trouvé les test unitaires autour de cette requete, et le code impliqué (app/service/BlockahainService.ts notamment requirementsOfIdentity()).
J’ai plusieurs pistes, mais j’aurais aimé avoir l’avis des dev (cc @cgeek) :
Éviter la phase de recherche dans la wot, lorsque :search est une pubkey :
Soit pas une regexp
Soit par une nouvelle URL du type /wot/requirements/pubkey/:pubkey
Paralléliser les nombreux appels fait dans requirementsOfIdentity(), avec Promise.all(). Mais cela va complexifier la lecture du code. Ce n’est peut pas top ?
Faire une test unitaire avec de la charge, pour mesurer le gain. Mais il me faudrait générer un WoT importante. Y a t’il moyen de faire autrement ? Par exemple existe t il des tests sur une BDD de prod ?
Question niveau IDE :
webstorm me lance toujours 2 fois les tests unitaires, je ne comprends pas bien pourquoi. D’une manière général, j’aurais bien aimé un peu d’aide @cgeek pour configurer mon IDE.
Aurais 15 min à m’accorder pour une visio ?
Une pubkey valide est une valeur légale pour un pseudo, donc avec la solution regex il y a une ambiguïté. La deuxième solution me semble plus propre (en gardant l’ancien chemin qui cherche dans les pseudos et pubkeys, pour la rétrocompatibilité).
Mieux vaut éviter les regex (comme en atteste le dernier gros bug de Duniter, et parce que c’est lent), pour détecter une pubkey il suffit de la décoder ou de vérifier sa longueur et ses caractères.
Oui, cela me semble aussi une solution plus propre.
Pourrais tu m’aider @tuxmain côté mise en oeuvre de l’environnement de dev ? (même sans parler de WebStorm)
A priori, @moul me dit que Silkaj utilise /wot/requirements/:search comme Cesium : uniquement avec une pubkey.
Plutot que de créer une nouvelle URL, je me demande donc si ce n’est pas mieux de faire simplement évoluer celle-ci en /wot/requirements/:pubkey. Cela permettrait de rendre tous les clients plus rapide, sans mise à jour logicielle.
Est-ce que d’autres logiciels utilise cette URL BMA ? cc @Paidge@vit@tuxmain@gerard94@HugoTrentesaux@poka …
D’ailleurs, j’ai la même question pour les URL /wot/certified-by et /wot/certifiers-of : N’est-ce pas toujours la pubkey qui est requeteée ?
On pourrait corriger cela aussi, ou bien ajouter des URL /wot/certified-by/pubkey/:pubkey et /wot/certifiers-of/pubkey/:pubkey
Le problème d’ajouter de nouvelle URL, c’est que les noeuds qui n’auront pas été mises à jour deviendront incompatible avec Cesium…
Une autre alternative est d’ajouter plutot un “query param” à la requete, par exemple : /wot/requirements/:search?pubkey=true&uid=false
A vrai dire, je ne maîtrise pas BMA et ne sait pas bien à quoi corresponds :search en dehors d’une pubkey, c’est un script selon Duniter c’est ça ?
De mon côté je ne connais aucun service utilisant autre chose qu’une pubkey à cet endroit (dans ce que j’ai implémenté comme g1-stats par exemple).
Il faudrait confirmation de @Paidge pour wotwizard-ui mais je pense qu’il ne se base que sur le serveur wot-wizard, qui lui se base uniquement sur les bases de données de Duniter directement et des fichiers tampon.
Ca me semble une bonne idée, ça permet de ne pas casser la compatibilité avec les versions de Cesium et Duniter tout en gardant la possibilité des recherches avancés.
Mais mon humble avis perso est de ne pas t’embêter avec ces recherches avancés qui ne semblent pas implémentés nul part (attendre confirmation de Paidge tout de même), et de simplifié l’API à ce niveau si cela permet des gains en efficacité.
C’est soit une pubkey, soit un uid (ou une partie de).
Ce qui est étrange, c’est que l’implémentation depuis LevelDB n’est plus la même que quand Duniter utilisait SqlLite. LevelDB fait l’équivalent d’un like; sous SQLLite c’était un uid = ? or pubkey = ?
Bref.
Après vérification du script de @tuxmain pour la wotmap, il va chercher directement dans "~/.config/duniter/duniter_default/data/leveldb".
Pour wotwizard-ui, c’est effectivement un serveur Wotwizard qui est interrogé. Donc, pas d’impact de ce côté- là
Même si je ne m’y connais pas tellement côté Duniter, je pense que pouvoir requêter directement sur une clé permettrait sûrement de gagner en temps de réponse (ça me paraît logique en tous cas).
Perso j’ai jamais utilisé d’API Duniter, sauf dans Datajune où je récupérais uniquement les blocs avec /blockchain/block/000. Par contre sur la v2, je devrais pouvoir répondre à toutes les questions ><.
Merci @Pini !!
Je viens de tester : on est passé de 30s à 3s sur ton instance donc gain x10
Sur g1.duniter.org, ont devrait passer à 200ms, ce qui me semble déjà plus acceptable.
$ npm run format:check
> duniter@1.9.0-dev format:check /builds/nodes/typescript/duniter
> prettier --list-different 'app/**/*.{ts,json}'
app/lib/dal/indexDAL/leveldb/LevelDBIindex.ts
app/lib/dal/indexDAL/sqlite/SqliteIIndex.ts
app/lib/dal/sqliteDAL/IdentityDAL.ts
app/modules/bma/lib/controllers/wot.ts
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! duniter@1.9.0-dev format:check: `prettier --list-different 'app/**/*.{ts,json}'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the duniter@1.9.0-dev format:check script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/user/.npm/_logs/2023-05-16T14_33_27_147Z-debug.log
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: exit code 1
