8000 bench: Add OrphanTxPool benchmark by hebasto · Pull Request #19377 · bitcoin/bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

bench: Add OrphanTxPool benchmark #19377

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

Closed
wants to merge 1 commit into from

Conversation

hebasto
Copy link
Member
@hebasto hebasto commented Jun 25, 2020

This PR adds a new benchmark for adding/evicting orphan transactions to/from the mapOrphanTransactions.

This benchmark could be useful while considering relevant code changes (e.g., #19374) or changing the DEFAULT_MAX_ORPHAN_TRANSACTIONS parameter.

The output example:

$ ./src/bench/bench_bitcoin -filter="OrphanTxPool"
# Benchmark, evals, iterations, total, min, max, median
OrphanTxPool, 5, 10000, 2.3938, 4.76101e-05, 4.83722e-05, 4.77407e-0

@naumenkogs
Copy link
Member

utACK 059c8e6

@jnewbery
Copy link
Contributor

@hebasto can you provide motivation for this change? In practice, only one orphan transactions is ever evicted at a time (in LimitOrphanTxSize() which is only called after the 101st orphan has been added. Picking a random element from a 101-entry container is always going to be fast, whatever the underlying data structure, so I don't think there's any benefit to having a microbenchmark for this. On the other hand, there is a cost to adding it - it means that there's more work involved in changing or reviewing changes to the interface.

@hebasto
Copy link
Member Author
hebasto commented Jun 25, 2020

@jnewbery

@hebasto can you provide motivation for this change?

It was motivated by discussion with @sipa in #19374.

@jnewbery
Copy link
Contributor

I'm a -0.5 on this. I don't think it's worth adding a microbench for a different usage pattern than is used in the product, and for something that is always going to be quick.

@maflcko
Copy link
Member
maflcko commented Jun 25, 2020

microbenchmarks are never going to match the exact usage pattern in the end product. This is true for all existing microbenchmarks (like the mempool eviction one, etc ...). Absent the details, I think having a benchmark is slightly preferable to not having a benchmark because it might catch accidental performance regressions.

And since we don't have any user-facing compatibility concerns for tests in general, adding and removing tests can be done much more easily than (let's say) an RPC method. In general I think that the cost of a pull request that adds a test that passes can only be negative or null (when it is testing nothing). And it should always be an uncontroversial option to remove a not-too-useful test that is in the way of other changes/refactoring/features.

I haven't looked at the specifics of this pull request, but I think in general we need more benchmarks (or fuzzers) for p2p tx relay, as that is the primary DoS attack vector on the live network.

@DrahtBot
Copy link
Contributor
DrahtBot commented Jun 25, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@jnewbery
Copy link
Contributor

In general I think that the cost of a pull request that adds a test that passes can only be negative or null (when it is testing nothing). And it should always be an uncontroversial option to remove a not-too-useful test that is in the way of other changes/refactoring/features.

I'm sorry - this is wrong. All code added to the repo has a cost - in maintenance, in review, in discussion as to whether to remove it later. Tests/benches should only be added if they're useful.

Copy link
Member
@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK. I think adding a benchmark for orphan handling is useful and needed

LOCK(g_cs_orphans);
SweepOutExpiredOrphans();
return EvictOrphanTxs(nMaxOrphans);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is net_processing changed in a pull that adds a benchmark? Seems unnecessary to me

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To benchmark EvictOrphanTxs() without sweeping out functionality of the current LimitOrphanTxSize().

What could you suggest to change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you explicitly want to disable the time based eviction, it could be done with mocktime in the benchmark, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hebasto
Copy link
Member Author
hebasto commented Jun 26, 2020

Updated 059c8e6 -> 2ee8c0b (pr19377.01 -> pr19377.02, diff):

@hebasto
Copy link
Member Author
hebasto commented Aug 2, 2020

Rebased 2ee8c0b -> b0a5761 (pr19377.02 -> pr19377.03) due to the conflict with #18011.

}

bench.batch(txs.size()).unit("byte").run([&] {
WITH_LOCK(g_cs_orphans, for (const auto& tx : txs) { AddOrphanTx(tx, 0); });
Copy link
Member
@jonatack jonatack Jun 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK. Had a look as this "conflicts" with #22284, rebased it to current master and began building; it needs updating here and line 17 above:

bench/orphan_tx_pool.cpp:17:83: error: use of undeclared identifier 'g_cs_orphans'
bool AddOrphanTx(const CTransactionRef& tx, NodeId peer) EXCLUSIVE_LOCKS_REQUIRED(g_cs_orphans);
                                                                                  ^
bench/orphan_tx_pool.cpp:37:19: error: use of undeclared identifier 'g_cs_orphans'
        WITH_LOCK(g_cs_orphans, for (const auto& tx : txs) { AddOrphanTx(tx, 0); });
                  ^
bench/orphan_tx_pool.cpp:37:19: error: use of undeclared identifier 'g_cs_orphans'
3 errors generated.

@jnewbery
Copy link
Contributor

Had a look as this "conflicts" with #22284, rebased it to current master and began building; it needs updating here and line 17 above:

This also conflicts with #21527, which is blocking quite a lot of important work in net_processing.

@hebasto hebasto marked this pull request as draft June 23, 2021 00:19
@hebasto
Copy link
Member Author
hebasto commented Jun 23, 2021

Marked this as a "draft" for now.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

@DrahtBot
Copy link
Contributor
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@hebasto hebasto closed this Apr 21, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3F73 Development

Successfully merging this pull request may close these issues.

7 participants
0