Fixes #22382
Motivation: prevent excessive disk reads if txindex is enabled.
Worth noting that this could be argued to be less of a bug and more of an issue of undefined behavior. If a user calls GetTransaction with the wrong block hash, what should happen?
It looks like an empty line needs to be added to the commit message after the subject line for the linter to pass.
I think this would change the behavior of GetTransaction in some cases. I'm not sure whether this is OK or not, but I'd think we should at least update comments here: https://github.com/bitcoin/bitcoin/blob/master/src/validation.h#L146, and docs here: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L78
The case I'm thinking about, which you noted, is when an incorrect block_index is provided to GetTransaction, but g_txindex->FindTx(hash, hashBlock, tx) finds and returns the tx. After this PR we would return the tx although it isn't in the block the user asked for. Idk the implications of this or if it matters, but if it does, you could probably check hashBlock against the user provided block_index and get the performance win you want without changing behavior (if necessary/practical)
Similarly, I'm not sure if checking the mempool first has any unintended consequences (other than deviating from current docs). That said, I'm not sure the if (mempool) { branch needs to move in this PR, can probably just leave it after the if (block_index) { branch as is. Again, not sure how we feel about returning a tx from the mempool when the user wanted to check a specific block_index
I think a fundamental question is whether or not the block_index is intended to be used as a hint or as a validation parameter.
Given that the current logic of this function has various fallbacks, it seems to me that block_index is a hint and that the goal of the function is to try to return the requested transaction regardless of where it is stored. So it seems to me that reorganizing the logic for performance gains is a suitable goal.
FindTx returns the block hash, so it's very easy to check if it matches. If you do so, the question of whether the provided block is a hint or a search restriction doesn't apply.
141 | @@ -142,15 +142,16 @@ void StartScriptCheckWorkerThreads(int threads_num); 142 | /** Stop all of the script checking worker threads */ 143 | void StopScriptCheckWorkerThreads(); 144 | /** 145 | - * Return transaction from the block at block_index. 146 | - * If block_index is not provided, fall back to mempool. 147 | - * If mempool is not provided or the tx couldn't be found in mempool, fall back to g_txindex. 148 | + * Return transaction with a given hash. 149 | + * If mempool is provided, check it first for the tx. 150 | + * If g_index is available, check it next for the tx.
g_index? How about If -txindex is enabled, check it next for the tx.
Sure; will update.
1163 | + CTransactionRef ptx = mempool->get(hash); 1164 | + if (ptx) return ptx; 1165 | + } 1166 | + if (g_txindex) { 1167 | + CTransactionRef tx; 1168 | + if (g_txindex->FindTx(hash, hashBlock, tx)) return tx;
Something like the following would keep behavior?
uint256 block_hash;
if (g_txindex->FindTx(hash, block_hash, tx)) {
if (block_index && block_index->GetBlockHash() != block_hash) return nullptr;
hashBlock = block_hash;
return tx;
}
Note the local block_hash to avoid changing the out-arg in case it fails.
Makes sense; I can add a similar check for the mempool condition.
153 | * @param[in] block_index The block to read from disk, or nullptr 154 | * @param[in] mempool If block_index is not provided, look in the mempool, if provided 155 | * @param[in] hash The txid 156 | * @param[in] consensusParams The params 157 | - * @param[out] hashBlock The hash of block_index, if the tx was found via block_index 158 | + * @param[out] hashBlock The block hash, if the tx was found via g_txindex or block_index
same, ... via -txindex or ...
Sure; will update.
This is a behavior change, and no test fails which is unfortunate. If we want to do this then a release note would be nice.
I've added additional checks that should ensure there is no behavior change, only performance improvements. Now it should return nullptr faster in certain conditions.
1158 | @@ -1159,6 +1159,24 @@ CTransactionRef GetTransaction(const CBlockIndex* const block_index, const CTxMe 1159 | { 1160 | LOCK(cs_main); 1161 | 1162 | + if (mempool) { 1163 | + CTransactionRef ptx = mempool->get(hash); 1164 | + if (ptx) { 1165 | + // Transaction was found in mempool but we were searching for it in a block.
It could be an orphaned block and tx went back to the pool? I think previously it would return the transaction.
Might be better just do if (mempool && !block_index) { in L1162?
👍🏼
1166 | + if (g_txindex) { 1167 | + CTransactionRef tx; 1168 | + uint256 block_hash; 1169 | + if (g_txindex->FindTx(hash, block_hash, tx)) { 1170 | + // Transaction was found in a different block than requested. 1171 | + if (block_index && block_index->GetBlockHash() != block_hash) return nullptr;
Really edge case but I think this should be:
if (!block_index || block_index->GetBlockHash() == block_hash) {
hashBlock = block_hash;
return tx;
}
So if the block hash doesn't match with the index then fall thru the next check - the transaction can be in another block right?
indeed
This shouldn't happen, though, as the FindTx wouldn't return true?
txindex only keeps 1 block hash right?
Oh, I didn't think of BIP 30
Also, block_index could be an orphaned block where the transaction is but in the index the block is the one in the chain.
review ACK 5dd11ea1406f4926ab9061702b69b409459723b4
78 | - "argument, getrawtransaction will return the transaction if the specified block is available and\n" 79 | - "the transaction is found in that block. When called without a blockhash argument, getrawtransaction\n" 80 | - "will return the transaction if it is in the mempool, or if -txindex is enabled and the transaction\n" 81 | - "is in a block in the blockchain.\n" 82 | - 83 | + "\nBy default this function only returns a transaction if it is in the mempool. If -txindex is enabled\n"
nit if you retouch
"\nBy default, this call only returns a transaction if it is in the mempool. If -txindex is enabled\n"
1169 | + if (g_txindex->FindTx(hash, block_hash, tx)) { 1170 | + // Transaction was found in a different block than requested. 1171 | + if (block_index && block_index->GetBlockHash() != block_hash) return nullptr; 1172 | + hashBlock = block_hash; 1173 | + return tx; 1174 | + }
#22383 (review) seems preferable, otherwise move comment to the right place (or omit it)
@@ -1167,8 +1167,10 @@ CTransactionRef GetTransaction(const CBlockIndex* const block_index, const CTxMe
CTransactionRef tx;
uint256 block_hash;
if (g_txindex->FindTx(hash, block_hash, tx)) {
- // Transaction was found in a different block than requested.
- if (block_index && block_index->GetBlockHash() != block_hash) return nullptr;
+ if (block_index && block_index->GetBlockHash() != block_hash) {
+ // Transaction was found in a different block than requested.
+ return nullptr;
+ }
hashBlock = block_hash;
return tx;
Concept ACK 5dd11ea1406f4926ab9061702b69b409459723b4
ISTM we could use additional test coverage. Edit: Am adding some, will propose separately.
Fixes #22382
ACK 78f4c8b98eada337346ffb206339c3ebae4ff43b
Concept ACK
79 | - "the transaction is found in that block. When called without a blockhash argument, getrawtransaction\n" 80 | - "will return the transaction if it is in the mempool, or if -txindex is enabled and the transaction\n" 81 | - "is in a block in the blockchain.\n" 82 | - 83 | + "\nBy default, this call only returns a transaction if it is in the mempool. If -txindex is enabled\n" 84 | + "and no blockhash argument is passed, it will return the transaction if it is in the mempool or any block.\n"
nit: there is the case where -txindex is enabled and a blockhash argument is passed, where it will return the transaction only if the block it's found in matches the blockhash argument passed
NACK -- In general, I think performance optimizations should come with data that shows they improve things. Especially in the case the code isn't being cleaned up or simplified (I think this PR makes the code slightly more complicated and harder to follow so I'd want to be sure the performance improvements warrant it). I also have other concerns which I lay out below. I can quickly come around on my review with some explanation/correction to my understanding if I'm off base anywhere.
Motivation: prevent excessive disk reads if txindex is enabled.
However, from #22382 which this PR fixes, the issue is reported as:
When using getrawtransaction with an included blockhash, performance should be better as there is no need to scan the entire txindex.
Was the issue misread? Because the issue expects scanning the entire txindex causes a slowdown, while this PR claims excessive disk reads (in the case that txindex is enabled) causes a slowdown. So to me the two seem to contradict each other.
To me it seems both ReadBlockFromDisk and g_txindex->FindTx do the same disk read, so I'm not sure how this change "prevents excessive disk reads" (please correct me if I'm misunderstanding something basic, I'm learning):
If I'm understanding this correctly, the main benefit of txindex being enabled is that we don't need blockhash to be specified to know which block to look in for the transaction, so we can still find it, but the same disk read is happens in both cases.
Now the measurements provided in the issue seem to show some performance discrepancy (which maybe @jlopp just looked at and knew what was going on right away). But I also don't know how much variation is normal in the timing of rpc calls, and whether one measurement (under unknown conditions) is good enough to warrant a performance optimization. On top of that it's only one data point - what if this tx reported in the issue happens to be at the beginning/end of txindex or who knows what?
To me it seems both
ReadBlockFromDiskandg_txindex->FindTxdo the same disk read, so I'm not sure how this change "prevents excessive disk reads" (please correct me if I'm misunderstanding something basic, I'm learning): @mjdietzx txindex stores the transaction position in the block, so it just seeks there to parse the transaction. Without txindex it needs to load the block - parse transactions, build hashes,... - and then search in those transactions.
txindex stores the transaction position in the block, so it just seeks there to parse the transaction. Without txindex it needs to load the block - parse transactions, build hashes,... - and then search in those transactions.
Makes sense, and thanks for the explanation @promag. So is it safe to say scanning through the entire txindex and then "seeking to the tx's position in the block and reading it from disk" is much faster than " load the block - parse transactions, build hashes,... - and then search in those transactions"? Do we have any intuitions here, like big-O and/or worst-case runtimes?
If so, is it worth adding some good comments to the source code (not sure whether they are added in GetTransaction or in the ReadBlockFromDisk and FindTx declarations). Note, I have no intuition of the runtimes of these operations (due to my inexperience) so just lmk if this is obvious and unnecessary.
But here's where I'm coming from - how do I know the test measurements provided in #22382 are on mainnet (what if they are on some testnet where the txindex is extremely small? I can't find the transaction or block hashes from that issue in any block explorers). How do I even know -txindex is enabled for these measurements (and it's not just scanning through his wallet's transactions, and that's where the performance discrepancy comes from)?
Without some source code comments and data/measurments showing the performance differences here, it makes me wonder if the reason people pass block_hash in the first place is because it gets around scanning the entire txindex.
I don't believe that "scanning through the entire txindex" is an accurate way to describe how txindex->FindTx functions. I expect it to be more of a O(1) constant time operation while ReadBlockFromDisk() is more of a O(n) operation that is directly correlated to block size.
FWIW, this is the compared performance with @jlopp's modifications
$ time ./src/bitcoin-cli getrawtransaction 20a93350cd6f4e03dfb6cbb3f104965293627f25c199c1be0e4d187a4ed5f4bb
020000000001018d3f7d8efaa377dda74892af26c1ca028466d97721d2ea6c74a5cbcf404feb9004000000171600147f5a49a2d89f86ff498103bdbcb1762f9f0ab5aefeffffff08a04a05000000000017a91467a849785bb12f1a03260b3b52ec9dff52b30e708724b80100000000001976a914f0b7e8a5ede232c2654fca3b47f8d0c95f7a561688ac50fe0b00000000001976a914ed06524fb21248a37e7f8f20cdc67e27f49c4f1588acf44f01000000000017a9147422dbf3bdf441a640d09a2a91e6fa40837b019f878d9b3100000000001976a9142a5cd9333e4e94c88f7cd33216b2fc0af15fbd8588ac89b400000000000017a914d05dbcdb4587f1a243cc1ed89e96cd4ec19e24a08778e169180000000017a914f520df8923419f60d9a76df60cfc7a0e3a3fc86f8708d806000000000017a9147246c684dd4890e9c8977e6312c30ecdea2b0a55870247304402205704dd3b6d8930e89c660011ab2f6a42aedcbde438d5f121998e3db6a66889310220054a506aee274f885229d6a9ed89eca17bac87dca401f9c63d07990e98b2f0a301210390e3b178ebc51da1589baee9de37de491dba0575838aacf88c2cd70a06a4486eb47c0a00
real 0m0.003s
user 0m0.002s
sys 0m0.000s
$ time ./src/bitcoin-cli getrawtransaction 20a93350cd6f4e03dfb6cbb3f104965293627f25c199c1be0e4d187a4ed5f4bb false 0000000000000000000a801776a92ced69dc5fb0a5919271872a9261a613d9c3
020000000001018d3f7d8efaa377dda74892af26c1ca028466d97721d2ea6c74a5cbcf404feb9004000000171600147f5a49a2d89f86ff498103bdbcb1762f9f0ab5aefeffffff08a04a05000000000017a91467a849785bb12f1a03260b3b52ec9dff52b30e708724b80100000000001976a914f0b7e8a5ede232c2654fca3b47f8d0c95f7a561688ac50fe0b00000000001976a914ed06524fb21248a37e7f8f20cdc67e27f49c4f1588acf44f01000000000017a9147422dbf3bdf441a640d09a2a91e6fa40837b019f878d9b3100000000001976a9142a5cd9333e4e94c88f7cd33216b2fc0af15fbd8588ac89b400000000000017a914d05dbcdb4587f1a243cc1ed89e96cd4ec19e24a08778e169180000000017a914f520df8923419f60d9a76df60cfc7a0e3a3fc86f8708d806000000000017a9147246c684dd4890e9c8977e6312c30ecdea2b0a55870247304402205704dd3b6d8930e89c660011ab2f6a42aedcbde438d5f121998e3db6a66889310220054a506aee274f885229d6a9ed89eca17bac87dca401f9c63d07990e98b2f0a301210390e3b178ebc51da1589baee9de37de491dba0575838aacf88c2cd70a06a4486eb47c0a00
real 0m0.003s
user 0m0.002s
sys 0m0.000s
ACK
Based on the issue being clarified and some measurements being provided after this PR, and tests in #22437 I'm signing-off on this. I do think this PR would have been a good opportunity to benchmark performance with a few different test cases (instead of times on just one transaction that @orweinberger provided), but that's just my opinion. Don't want to hold things up bc I'm convinced this is a good optimization
Code review ACK 78f4c8b98eada337346ffb206339c3ebae4ff43b
Using -txindex if available makes perfect sense, regardless of whether a blockhash has been passed or not. To my understanding, the PR in its current form doesn't change any behaviour (in particular, if the passed blockhash doesn't match the one from the index, still the slower path of reading the block from disk is taken), i.e. the initial objections by reviewers (https://github.com/bitcoin/bitcoin/pull/22383#issuecomment-872388955, #22383#pullrequestreview-697919335) have been sorted out. Follow-up PR #22437 should further increase the confidence that this is the case, will also put that on my review list.
Also, the structure of GetTransaction looks more logical now, as the code blocks for getting a transaction appear in the order of "fast" (mempool) to "slow" (read block from disk).
150 | + * If -txindex is available, check it next for the tx. 151 | + * Finally, if block_index is provided, check for tx by reading entire block from disk. 152 | * 153 | * @param[in] block_index The block to read from disk, or nullptr 154 | - * @param[in] mempool If block_index is not provided, look in the mempool, if provided 155 | + * @param[in] mempool If provided, check mempool for tx
* [@param](/bitcoin-bitcoin/contributor/param/)[in] mempool If provided and block_index is not, check mempool for tx
I'd suggest just replacing this with Optional pointer to the node's mempool to avoid duplicating what's already documented above.
tACK 78f4c8b98eada337346ffb206339c3ebae4ff43b suggestions are optional
1168 | + uint256 block_hash; 1169 | + if (g_txindex->FindTx(hash, block_hash, tx)) { 1170 | + if (!block_index || block_index->GetBlockHash() == block_hash) { 1171 | + hashBlock = block_hash; 1172 | + return tx; 1173 | + }
}
return nullptr;
Nit: This improves the performance of the (unlikely) case where a block hash is specified, but the transaction is found in the txindex but in a different block. The if at line 1170 would be false, so we would call ReadBlockFromDisk() below, but would not find the transaction there either (assuming the txindex is accurate).
I cherry-picked this PR with this suggestion onto #22437 as @jonatack described above, and the tests all pass.
How is this different from the initial solution: #22383 (review)?
@LarryRuane the idea is to allow fetching the transaction from a block out of the active chain - which -txindex doesn't take into account. Before this was possible.
That could be checked by seeing if the specified block index is in the main chain.
But I suppose even that has edge cases (eg, index out of sync), so maybe it's better to just leave it alone.
utACK 78f4c8b98eada337346ffb206339c3ebae4ff43b
Echo @LarryRuane's suggestion here https://github.com/bitcoin/bitcoin/pull/22383/files#r673899065
81 | - "is in a block in the blockchain.\n" 82 | - 83 | + "\nBy default, this call only returns a transaction if it is in the mempool. If -txindex is enabled\n" 84 | + "and no blockhash argument is passed, it will return the transaction if it is in the mempool or any block.\n" 85 | + "If -txindex is not enabled and a blockhash argument is passed, it will return the transaction if\n" 86 | + "the specified block is available and the transaction is found in that block.\n"
I think the following change addresses @mjdietzx's comment: https://github.com/bitcoin/bitcoin/pull/22383/files#r664172064
"If a blockhash argument is passed, it will return the transaction if\n"
"the specified block is available and the transaction is in that block.\n"
1166 | + if (g_txindex) { 1167 | + CTransactionRef tx; 1168 | + uint256 block_hash; 1169 | + if (g_txindex->FindTx(hash, block_hash, tx)) { 1170 | + if (!block_index || block_index->GetBlockHash() == block_hash) { 1171 | + hashBlock = block_hash;
This could do with a comment:
if (!block_index || block_index->GetBlockHash() == block_hash) {
// Don't return the transaction if the provided block hash doesn't match.
// The case where a transaction appears in multiple blocks (e.g. reorgs or
// BIP30) is handled by the block lookup below.
hashBlock = block_hash;
utACK 78f4c8b98eada337346ffb206339c3ebae4ff43b
Couple of minor documentation suggestions inline.
Code review ACK https://github.com/bitcoin/bitcoin/commit/78f4c8b98eada337346ffb206339c3ebae4ff43b
Doc updates as mentioned by @jnewbery #22383 (review) and #22383 (review) seems appropriate.
Would test #22437 and report back..
Code Review ACK and Tested ACK https://github.com/bitcoin/bitcoin/pull/22383/commits/78f4c8b98eada337346ffb206339c3ebae4ff43b on Ubuntu 20.04
1158 | @@ -1159,6 +1159,20 @@ CTransactionRef GetTransaction(const CBlockIndex* const block_index, const CTxMe
1159 | {
1160 | LOCK(cs_main);
Just realized after merge that cs_main is not needed to read from the mempool (only to write to it)
I was curious about response times so I ran some tests:
I picked up 5 random transactions and fetched them with and without the block hash against both latest release (v0.21.1) and 78f4c8b98eada337346ffb206339c3ebae4ff43b
v0.21.1 results
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 278e5e132279ef4bbb0a612cb6b27d8b7510c2cc3be432b0641841cf56a7b0d5
[...]
real 0m0.118s
user 0m0.000s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 278e5e132279ef4bbb0a612cb6b27d8b7510c2cc3be432b0641841cf56a7b0d5 false 0000000000000000000611dd7a5bde18744ebd17dd0ee71123bb31c5a500f9c0
[...]
real 0m0.133s
user 0m0.005s
sys 0m0.001s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2ad5c8d13cc87293145eefbf4f6b4ee22859c75006266b335248ae402d1495f8
[...]
real 0m0.117s
user 0m0.006s
sys 0m0.001s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2ad5c8d13cc87293145eefbf4f6b4ee22859c75006266b335248ae402d1495f8 false 00000000000000000070de9aec218ad077a877f8061cf990ab321dbd2753bfbc
[...]
real 0m0.043s
user 0m0.006s
sys 0m0.000s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction b9d34e525aa764d7043abb2c83d51394ada5162d6c1a352047bc388de8845e4b false 000000000000000006cd4488b5c44d79983f466fc2e7821cb309e0523dee0e52
[...]
real 0m0.090s
user 0m0.000s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction b9d34e525aa764d7043abb2c83d51394ada5162d6c1a352047bc388de8845e4b
[...]
real 0m0.112s
user 0m0.000s
sys 0m0.005s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction c2def6c34dd508a36776ac76eab06391f1ce90fdb142355b6ddd4fdb90b60f24 false 00000000000004fa9ea9acff9060083ea60f9377589e6797bb132484263f4b7c
[...]
real 0m0.021s
user 0m0.003s
sys 0m0.004s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction c2def6c34dd508a36776ac76eab06391f1ce90fdb142355b6ddd4fdb90b60f24
[...]
real 0m0.102s
user 0m0.005s
sys 0m0.001s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2722e08668a07b515d57a80922c2348c6a857f9afd1fa456851d489edc39b9e6
[...]
real 0m0.154s
user 0m0.000s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2722e08668a07b515d57a80922c2348c6a857f9afd1fa456851d489edc39b9e6 false 00000000000536414be8da7f69059a812bab7623ebd25abd779d1d24b06110fc
[...]
real 0m0.006s
user 0m0.002s
sys 0m0.003s
78f4c8b98eada337346ffb206339c3ebae4ff43b results
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 278e5e132279ef4bbb0a612cb6b27d8b7510c2cc3be432b0641841cf56a7b0d5
[...]
real 0m0.095s
user 0m0.001s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 278e5e132279ef4bbb0a612cb6b27d8b7510c2cc3be432b0641841cf56a7b0d5 false 0000000000000000000611dd7a5bde18744ebd17dd0ee71123bb31c5a500f9c0
[...]
real 0m0.007s
user 0m0.002s
sys 0m0.005s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2ad5c8d13cc87293145eefbf4f6b4ee22859c75006266b335248ae402d1495f8
[...]
real 0m0.124s
user 0m0.001s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2ad5c8d13cc87293145eefbf4f6b4ee22859c75006266b335248ae402d1495f8 false 00000000000000000070de9aec218ad077a877f8061cf990ab321dbd2753bfbc
[...]
real 0m0.009s
user 0m0.000s
sys 0m0.007s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction b9d34e525aa764d7043abb2c83d51394ada5162d6c1a352047bc388de8845e4b false 000000000000000006cd4488b5c44d79983f466fc2e7821cb309e0523dee0e52
[...]
real 0m0.153s
user 0m0.003s
sys 0m0.004s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction b9d34e525aa764d7043abb2c83d51394ada5162d6c1a352047bc388de8845e4b
[...]
real 0m0.006s
user 0m0.006s
sys 0m0.000s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction c2def6c34dd508a36776ac76eab06391f1ce90fdb142355b6ddd4fdb90b60f24 false 00000000000004fa9ea9acff9060083ea60f9377589e6797bb132484263f4b7c
[...]
real 0m0.138s
user 0m0.000s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction c2def6c34dd508a36776ac76eab06391f1ce90fdb142355b6ddd4fdb90b60f24
[...]
real 0m0.006s
user 0m0.000s
sys 0m0.006s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2722e08668a07b515d57a80922c2348c6a857f9afd1fa456851d489edc39b9e6
[...]
real 0m0.158s
user 0m0.000s
sys 0m0.005s
nelson@bitcoin-node-v3:~$ time ./bitcoin-cli getrawtransaction 2722e08668a07b515d57a80922c2348c6a857f9afd1fa456851d489edc39b9e6 false 00000000000536414be8da7f69059a812bab7623ebd25abd779d1d24b06110fc
[...]
real 0m0.006s
user 0m0.005s
sys 0m0.000s
System information GCP n1-standard-2 2 vCPUs 7.5 GB memory HDD Standard Disk