This chart shows times taken for CP to parse recent blockchain blocks.
- Bitcoin Core 0.11.2 (https://github.com/btcdrak/bitcoin/releases/tag/v0.11.2-addrindex)
- Counterparty Server develop branch
- NL-SAS HDD
There’s no other workload (such as bitcoin CLI and counterparty client).
For some reason every now and then there are huge outliers that I haven’t been to figure out.
For example block https://blockchain.info/block-height/389326 took more than 4,800 seconds and had 1,692 bitcoin transactions and only 2 Counterparty transactions, so it would seem that the slowness comes from Bitcoin Core.
If we consider whether the previous block may have created a backlog of Counterparty transactions, the answer is no - http://blockscan.com/tx?block=389325 had only 7 Counterparty transactions. The same block had 774 Bitcoin transactions so while we may expect it took about 1,500 seconds to digest it (approximately 1/3 of 4,800 seconds), in fact it took only 68 seconds.
Looking at the longest parse times evidently the number of bitcoin transactions is invariably over 1,000 and the number of Counterparty transactions is close to zero.
The green line is smoothed to see if there’s a delay between peaks of BTC transactions that could potentially be attributed to addrindex, but this data series is too short (I looked only at the current server.log).
With this I have only two suspicions:
- addrindex behavior should be investigated with performance tracing tools
- it seems that worst delays appear when there’s over 1,000 bitcoin transactions per block
It is important to add that because of this outliers, Counterparty Server is behind the blockchain most of time, so although the chart doesn’t look too bad, it is bad. SSD seems a must-have to run the both services on one Pi.
Maybe I’ll take another look at this when I have nothing else to do