I have opened issue #1442 to improve the response time of the BMA /tx/history/:pubkey/pending endpoint.
Cesium makes this request every time the wallet is refreshed. Users may be waiting for a transaction sent by another user, making it necessary for us to retrieve this data from the network.
However, this request can take a considerable amount of time, depending on the performance of the Duniter node.
Upon closely examining the code, I realize that we are systematically accessing all transactions of the public key (the entire history) via the Rust database (in the server.rs file and getTransactionsHistory(pubkey)).
I’m wondering if it would be better to:
Either retrieve the pending transactions from the node first, then filter based on the public key?
We may use the function getTransactionsPending(versionMin = 0, medianTime = 0).
But what are these versionMin and medianTime arguments for? What would be the optimal values in my case?
Or create a getPendingTransactionsByPubkey(pubkey) method?
I think we can use function get_transactions_history_for_bma() as template, from duniter-gva module.
cc @cgeek @tuxmain
versionMin is the minimum document version for a transaction to be included in the result.
medianTime is not used. (see function get_pending_txs)
I’m not sure what would be the simpler or cleaner way, but if needed I can add something like get_pending_transactions_for_bma.
Merci @tuxmain pour ta réponse. J’ai ajouté deux fonction au module Rust duniter-gva :
get_written_transactions_for_bma() qui remplit uniquement sent/received
get_pending_transactions_for_bma() : qui remplit uniquement sending/pending
j’ai modifié get_transactions_history_for_bma() pour qu’il appelle les deux autres
Ca compile et les test passent. Youpi !
Maintenant, j’observe get_written_transactions_for_bma() et je vois que le code récupère toujours toutes les TX de la pubkey (le start_k et end_k inclus tous les blocs).get_written_transactions_for_bma(), je vais donc ajouter deux arguments (start_block et end_block) à dans pour être cohérent avec les paramètres possible de BMA.
Tout cela devrait grandement améliorer les perfs des clients utilisant BMA. Youpi
3 Likes
kimamila
17 May 2023 15:18
4
2 posts were merged into an existing topic: DĂ©bugger Duniter v1
J’ai fini 2 MR :
J’attends vos retours, @cgeek , @tuxmain , ou bien je merge direct ?
Je vois que @tuxmain tu as aussi des MR en attente. Est-ce toujours d’actualité ? Attends tu un retour particulier ?
1 Like
C’est bon pour moi. (je n’ai pas les droits sur les dépôts donc je ne peux ni approuver ni merger)
Ma MR sur duniter-core peut éventuellement éviter des crashes aux nœuds GVA mais je ne sais pas/plus si c’est déjà arrivé en production. Celles sur duniter-gva sont abandonnées, à moins que quelqu’un ait besoin de la requête idty_by_username.
J’ai les droits. Je peux lancer les merge si j’ai ton feu vert (je suis bien incapable de donner mon avis sur la MR elle-même
J’ai commencé à faire l’oxydation, et j’ai un soucis sur get_written_transactions_for_bma_with_range().@tuxmain ? Connais le système de recherche key/value qu’utilise duniter-gva ?
Est-ce du [start_k, end_k] ou du [start_k, end_k[ quand on fait :
// ... get_written_transactions_for_bma_with_range()
.iter_ref_slice(start_k..end_k, |_k, hashs| {
let mut sent = SmallVec::<[GvaTxDbV1; 2]>::new();
for hash in hashs {
if let Some(tx_db) = gva_db_ro.txs().get(HashKeyV2::from_ref(hash))? {
sent.push(tx_db);
}
}
Ok(sent)
})
en effet les ranges en Rust a..b incluent a et non b. Il faut faire end_block+1 pour l’inclure.
Edit: ou plutĂ´t end_block.saturating_add(1) sinon il y aura un panic pour end_block=u32::MAX.
cgeek
17 May 2023 19:42
10
Voilà qui est corrigé, je t’ai invité dans les Owners du groupe nodes/rust.
2 Likes
Merci @tuxmain du coup je m’en suis sorti pour les TX par plage de blocs. Ouf.
Tant que j’y suis, je vais ajouter à ma MR une fonction Rust pour retrouver les TX par plages de times. J’ai qu’il en existe une pour les pages graphql, mais elle utilise le median_time. Je ne sais plus pour BMA si c’était pareil.
Voila, j’ai eu du mal mais ca fonctionne : toutes les requetes suivantes ont été optimisé :
/tx/history/:pubkey/pending
/tx/history/:pubkey/blocks/:from/:to
/tx/history/:pubkey/times/:from/:to
J’ai testé sur un noeud DUniter à jour, (branche dev - donc ~1.9.x) : Cesium est maintenant hyper rapide ! 20ms à 100ms pour récupérer les sources, TX, et tout ce qu’il faut sur un compte.
bref, c’est aussi fluide qu’au début de G1
Il n’y a plus que se décider pour savoir ce qu’on fait : une 1.8 ou une 1.9 ?
Si c’est une 1.8, il faut savoir si le module de stocker Rust utilisé par GVA, que j’ai utilisé pour mes optimisation, était déployée…@cgeek ?
3 Likes
En cherchant “gva” dans le tag v1.8.6 la seule mention est dans un README, parlant au futur, alors que dans dev il y a plein d’occurrences dans le code. Je crois que le seul rôle du Rust en 1.8 est la PoW et une partie de la CLI, c’était surtout une expérimentation d’oxydation.
1 Like
Merci @tuxmain . Du coup, on va devoir définir une stratégie pour tester la v1.9@Pini ?
As tu des retours, Pini, de tout ça ? Ces nœuds 1.9 tournent bien et ne se désynchonisent pas ?
@cgeek qu’en penses-tu ? Si on fix les tests pour qu’ils passent sur la 1.9, on ne prend pas trop de risque, si ?
Pini
20 May 2023 07:29
15
Les noeuds en 1.9 se comportent correctement. Il peut y avoir des désynchro dues à des forks qui ont du mal à se résoudre, mais je ne pense pas que ce soit pire que les 1.8. Il y a au moins 1 bug qui a été résolu dans la 1.9 et pas dans la 1.8 qui permet à la synchro de mieux se passer.
kimamila:
Si c’est une 1.8, il faut savoir si le module de stocker Rust utilisé par GVA, que j’ai utilisé pour mes optimisation, était déployée…@cgeek ?
A priori, Duniter 1.8 n’utilise pas duniter-gva ni duniter-core. Les TX sont lues depuis la table SqlLite.block_number ou time, plutôt que de tout parser et filtrer en JS
1 Like
