bitcoind rpc api takes too long to respond to sendtoaddress

[noobcoder]

I'm developing web application, that communicates with bitcoind through JSON rpc api. Sometimes sendtoaddress call takes 30+ seconds to perform which is too long, as to me. Bitcoind version 100100 is installed on 8Gb RAM VPS. Any recommendations how to debug this? I need to find out why some requests are so slow. Any help will be appreciated.

[1715022330]

1715022330

[1715022330]

1715022330

[1715022330]

1715022330

[Muhammed Zakir]

You asked http://bitcoin.stackexchange.com/questions/37482/sendtoaddress-rpc-api-call-takes-too-long-to-execute? Looks like a good project!

I'm developing web application, that communicates with bitcoind through JSON rpc api. Sometimes sendtoaddress call takes 30+ seconds to perform which is too long, as to me. Bitcoind version 100100 is installed on 8Gb RAM VPS. Any recommendations how to debug this? I need to find out why some requests are so slow. Any help will be appreciated.

Is your wallet fully synced? If not, then it will not send Bitcoin until client is fully synced. CMIIW.

[noobcoder]

You asked http[Suspicious link removed]cute? Looks like a good project!

Is your wallet fully synced? If not, then it will not send Bitcoin until client is fully synced. CMIIW.

Yep, this question was asked by me. Wallet is fully synced

[goregrind]

Can you identify a pattern for the slow times ?
I'm thinking the slow times might relate to new found blocks which need to be processed and validated.
However 30s seems a bit too long.

[2112]

I'm developing web application, that communicates with bitcoind through JSON rpc api. Sometimes sendtoaddress call takes 30+ seconds to perform which is too long, as to me. Bitcoind version 100100 is installed on 8Gb RAM VPS. Any recommendations how to debug this? I need to find out why some requests are so slow. Any help will be appreciated.

30+ seconds is nothing. With sufficiently complex wallet it could take minutes to return from RPC call. With backups running in the background I've observed over 15 minutes to service complex sendmany requests.

The problem is unfixable with the current architecture.

If you really trying to develop something reliable you will have to monitor the wallet access directly through BerkeleyDB API and/or utilities. Start bitcoind with -privdb=0, create an appropriate DB_CONFIG and then you can monitor the wallet lock activity of the live bitcoind instance.