You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#3012 discusses how blocks often have few tx's in them.
This is a result of two things:
the timeout times to stop processing
the speed of tx processing
I have measured processing speed on my GCP box as
INFO [1643037789.034557] [src/chainstate/stacks/miner.rs:1934] [main] num_considered 269 seconds_elapsed 183.046 fraction 0.6804684014869888
This is about 1.47 transactions per second. This means that, to put 1k tx's in a block, it would take 680s=11minutes. This means that it will be hard to put 1k tx's in most blocks.
Maybe we can improve processing speed, to drastically fill more blocks. Eg. we can pre-cache the MARF look-ups that will be needed for a given set of mempool tx's before mining begins.
The text was updated successfully, but these errors were encountered:
Looks like query_row_and_then takes up most of the time, but not sure if the graph is showing the relationships right, in that it looks like these calls are outside of process_transaction, but that might not be true.
#3012 discusses how blocks often have few tx's in them.
This is a result of two things:
I have measured processing speed on my GCP box as
This is about
1.47
transactions per second. This means that, to put 1k tx's in a block, it would take680s=11minutes
. This means that it will be hard to put 1k tx's in most blocks.Maybe we can improve processing speed, to drastically fill more blocks. Eg. we can pre-cache the MARF look-ups that will be needed for a given set of mempool tx's before mining begins.
The text was updated successfully, but these errors were encountered: