Performance
The Ledger Recovery flow has been optimised to support large-scale recovery of transactions. This has been accomplished using a combination of:
- parallelism: when recovering against more than one peer.
- batching at several layers: reconciliation window, across-the-wire transfer of records and transactions, and database transactional updates.
Window narrowing uses a cryptographic hashing algorithm to rapidly determine the optimal recovery window for any given peer. Furthermore, internal state is kept to a minimum, thus enabling recovery to be resumed from the point it left off, should there be any interruption in service.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.