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
{{ message }}
This repository has been archived by the owner on Jan 8, 2019. It is now read-only.
Currently no public calls are resulting in an additonal call to bitcoind over JSON-RPC. Unlike in the very first versions of overnode, all data that the public consumes is served from postgres. We could potentially open up more functionality and reduce the amount of data needed to be duplicated into postgres if we can allow some queries to be resolved by a call to bitcoind.
My initial reluctance to do this was due to the very conservative default maximum number of RPC requests that can be made concurrently. This is a setting that can be increased as a bitcoind parameter but I'm not sure of the downsides. Perhaps an increase in this setting plus a queuing mechanism would be workable. Googling around found this related thread htps://github.com/bitpay/insight-api/issues/492. However, unlike in their situation, we reverse proxy overnode behind nginx which serves to rate limit queries and I don't believe we need to reinvent the wheel there.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently no public calls are resulting in an additonal call to bitcoind over JSON-RPC. Unlike in the very first versions of overnode, all data that the public consumes is served from postgres. We could potentially open up more functionality and reduce the amount of data needed to be duplicated into postgres if we can allow some queries to be resolved by a call to bitcoind.
My initial reluctance to do this was due to the very conservative default maximum number of RPC requests that can be made concurrently. This is a setting that can be increased as a bitcoind parameter but I'm not sure of the downsides. Perhaps an increase in this setting plus a queuing mechanism would be workable. Googling around found this related thread htps://github.com/bitpay/insight-api/issues/492. However, unlike in their situation, we reverse proxy overnode behind nginx which serves to rate limit queries and I don't believe we need to reinvent the wheel there.
The text was updated successfully, but these errors were encountered: