Quote from: nicehashdev on February 24, 2015, 06:56:13 PM

it blocks all RPC calls, including ones that wouldn't have to be blocked (such as getdiff or get new address)

The random RPC blocking you're describing sounds somewhat like what happens when you have a RPC client that leaks keepalives. With the default settings Bitcoin core has only 4 threads for handling rpc queries (as additional threads consume a fair amount of memory and people would like to run this stuff on 500 mb VPSes) and once it has that many keepalive connections open further ones will block. Many RPC client libraries leak connections, leaving open old keepalives for a long time with no intent to use them again. If this is your issue, you can forstall it (at some memory cost) by increasing the rpc thread count, or avoid it by disabling keepalive (-rpckeepalive=0)... (or better, fix your client to not leak keepalives).

If that isn't your issue, you could try actually reporting your problem (especially with a reproduction), since no one has done so. In particular, I keep a testing wallet running with tens of thousands of addresses and many thousands of transactions haven't observed what you're describing; so I cannot tell if your comment on block updating is a red herring or not (accepting a new block really must block most RPCs, but should also only take a second). Not sure why people are going on about software being "unsuitable" when they can't even be bothered to report issues they've had. It certainly isn't going to magically adapt to your use-case if you snark in threads burred on forums instead of reporting issues (much less contributing to improvements).

With respect the thread here, I benchmarked a node here processing over 5500 tx/s in aggregate during IBD, including the signature validation and all. Considering that the network as a whole is limited to <10, I think this is pretty good. If there is an actual performance issue you'll need to setup a reproduction in isolation from your application in order to figure out where it is. Just saying it's slow for you is very much not helpful; we need to know what RPCs, called in what pattern, are taking what amount of time-- and ideally have just some script to reproduce it, otherwise there is just an endless loop of "seems fast to me".