Address subscriptions are slow for addresses with large histories #18

Closed
opened 2022-04-05 21:30:32 +02:00 by jackrobison · 0 comments
jackrobison commented 2022-04-05 21:30:32 +02:00 (Migrated from github.com)

When a client subscribes to an address the hub needs to send it the hash of the address history to minimally allow the client to check that it has the same history. Currently this is an expensive call that the hub must do, where it has to concatenate the history and then hash it. As the address history grows the heaviness of recalculating the status hash grows with it.

This can be fixed by moving the calculation of address statuses into two new indexes maintained by the block processor: one for address statuses at the new block and another for address statuses factoring in mempool.

When a client subscribes to an address the hub needs to send it the hash of the address history to minimally allow the client to check that it has the same history. Currently this is an expensive call that the hub must do, where it has to concatenate the history and then hash it. As the address history grows the heaviness of recalculating the status hash grows with it. This can be fixed by moving the calculation of address statuses into two new indexes maintained by the block processor: one for address statuses at the new block and another for address statuses factoring in mempool.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/hub#18
No description provided.