I guess there is no limit. But on tests, what is the maximum before the bitcoind start to slow down in a specific machine?
2
-
1Well... test it, I would say. There is no way we can know this, unless we do some proper bench marking, which you can do better for your specific needs.– JoriCommented Apr 28, 2014 at 11:21
-
I will do it, thank you @Jori. I just post here to see if anyone have done this test before. It is a nice test to do.– FelipeCommented Apr 28, 2014 at 22:58
Add a comment
|
1 Answer
A while ago I created an extension for BitcoinLib in order to put bitcoind to the test. The setup was trivial: call getnewaddress() in the main network for ever
My performance index was the number of addresses generated per second.
It took off on an average of 35 addresses/sec. I left it running on a VM for a whole month. The rounded results were:
Total empty receiving addresses Generated addresses/sec
< 650,000 35
< 960,000 32
< 1,240,000 29
........... ..
< 75,000,000 28
The most noticeable slowdown was from 700,000 to 1,300,000.
Restarting the test client from the 75,000,000 point didn't improve the newly generated addresses per second rate. Restarting the host didn't make any difference either.
I then sent 3 payments to that wallet and they showed up instantly.
I don't know how it would affect the wallet if there were transactions linked to each of the 75 million receiving addresses but it would be really interesting to see. One thing also to be tested is whether or not there are delays during the daemon initialization when the wallet contains such a big number of addresses.
If someone has a really fast spare machine I could share the testing code and we could get to the 100 million benchmark much faster than in a month. Freewil's testnet box could be useful for that test.
Also, some related questions:
Does the original Bitcoin client scale to contain millions of addresses?
