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
2019 08 16 process header optimization #701
2019 08 16 process header optimization #701
Conversation
chain/src/main/scala/org/bitcoins/chain/blockchain/Blockchain.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/Blockchain.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/Blockchain.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/Blockchain.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/BlockchainUpdate.scala
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Outdated
Show resolved
Hide resolved
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Show resolved
Hide resolved
…), this decouples 'BlockchainUpdate' and Blockchain.connectTip(). This was needed because it doesn't make sense to have a Vector[BlockHeaderDb] returned from Blockchain.connectTip() as we are validating one header. However, to execute batch inserts, we need to accumulate headers somewhere. I choose to do this in BlockchainUpdate with the 'successfulHeaders' field.
31d9e31
to
9c3ea41
Compare
…s out extraneous noise in another test case
With #708 in master the results for running the test case that is most similar to header processing is this one.
and this branch (9c3ea41)
|
So I pushed up another commit (b206d8d) that creates a specific test case to call Here is current master with my new test case (1619d5d)
and here is the results from b206d8d
As you can see there is a pretty significant time reduction here from 17 seconds to 5 seconds. Here is the method that was being called in previous measurements, and as you can see it doesn't even call |
chain/src/main/scala/org/bitcoins/chain/blockchain/Blockchain.scala
Outdated
Show resolved
Hide resolved
} | ||
} | ||
val headersToBeCreated = { | ||
blockchainUpdates.map(_.successfulHeaders).flatten.distinct.toVector |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also map
and flatten
to flatMap
chain/src/main/scala/org/bitcoins/chain/blockchain/ConnectTipResult.scala
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
* WIP: implement processHeaders() in ChainHandler instead of processHeader() * Create ConnectTipResult which is returned from Blockchain.connectTip(), this decouples 'BlockchainUpdate' and Blockchain.connectTip(). This was needed because it doesn't make sense to have a Vector[BlockHeaderDb] returned from Blockchain.connectTip() as we are validating one header. However, to execute batch inserts, we need to accumulate headers somewhere. I choose to do this in BlockchainUpdate with the 'successfulHeaders' field. * make chain-verification log level INFO * Add unit test for benchmarking ChainHandler.processHeaders() that cuts out extraneous noise in another test case * Address code review
This is part of #653
Previously, we were inserting block headers after every tip validation instead of batching them. The goal of this PR is to batch these headers to insert them into the database all at once, to reduce database latency in our tip validation process.
8ba9626 (current master)
31d9e31
As the tests indicate, it seems like we have slightly regressed in at least running the test suite. I don't think this will be true when syncing the real chain though. Our chain tests sync insert roughly 10,000 headers, which is a relatively small sample size to a real chain.
It also looks like @nkohen found that the optimal insert size is not 2,000 -- which is the default number a node will send to us one the network at one time -- but has used batch sizes of 500 in our
ChainUnitTest