Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring query utxo by address command performance on par with current version #205

Closed
Tracked by #28
dnadales opened this issue Oct 11, 2022 · 6 comments
Closed
Tracked by #28
Assignees
Labels

Comments

@dnadales
Copy link
Member

QA reported that the query utxo --address command took about 10 seconds. The baseline (1.35.0 at the time of testing) took ~2.3 seconds. Furthermore, the query returned an empty set of addresses where 4 addresses were expected.

We need to fix the command and bring the performance of said command on par with the baseline.

This query is inefficient in LMDB because

  • we need to do disk access AND
  • we do it incrementally AND
  • we need to stow the ledger tables.

This query is inefficient in InMemory because

  • we do it incrementally AND
  • we need to stow the ledger tables.

Possible solutions:

  • InMemory can do the query all at once, no need to do it incrementally (8s > 5s).
  • Make the UTxO filtering functions target the CardanoLedgerTables and then stow the result (should take us to the theoretical limit).
  • Make this query faster, for instance by indexing by addresses.
  • Create a service to answer this query.
@dnadales
Copy link
Member Author

@jasagredo said:

For reference, returning the whole UTxO at once in the InMemory backend, measuring the time spent in stowLedgerTables (can ignore the bottom part, only the first 4 lines are relevant).

cardano-node timed

@dnadales
Copy link
Member Author

We should deprecate this query in the node (not in the cardano-cli!), and move it to an external service that maintains this index. cardano-cli can provide this functionality through said indexing service. Efforts to implement this query in this way are tracked in this issue.

As for this issue, I think to close it we need to:

do the query all at once in the InMemory backend, no need to do it incrementally (8s > 5s).

CC: @jasagredo @vfrsilva @disassembler

@jasagredo
Copy link
Contributor

As this is now being tracked by IntersectMBO/cardano-node#4678 I will close this one. Reopen it if you think otherwise @dnadales

@dnadales
Copy link
Member Author

Until #4678 is completed we still need to maintain baseline performance of this query I think.

@jasagredo
Copy link
Contributor

jasagredo commented Sep 5, 2023

@jasagredo jasagredo moved this from 🏗 In progress to 👀 In review in Consensus Team Backlog Sep 11, 2023
jasagredo added a commit that referenced this issue Sep 15, 2023
# Description
This PR leaves out the implementation for the `LegacyCardanoBlock`,
which will be implemented when needed.

Part of #205
@jasagredo
Copy link
Contributor

Closing as complete!

@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Consensus Team Backlog Sep 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants