Use LFU caches for address status and history calculation in scribe and herald #65

Merged
jackrobison merged 6 commits from lfu-cache into master 2022-07-31 21:38:53 +02:00
jackrobison commented 2022-07-29 15:48:44 +02:00 (Migrated from github.com)

This replaces existing LRU caches with LFU caches (used calculating address statuses and reading address histories), as to have a better overall hit rate by better keeping the intersecting sets of historical txids that are in the histories for many addresses as they are used in new txs in mempool/blocks.

With the new cache type the --cache_all_tx_hashes setting is no longer needed to quickly keep up mempool and new blocks with --index_address_statuses, this saves quite a bit of memory for similar performance, down from ~15gb to ~6gb. With the scribe default --history_tx_cache_size of 4194304 the cache will have an average hit rate of ~88%, going to 98-100% during load spikes, which gives it close enough performance to having the list of items being cached entirely stored in memory, but for less resources needed.

This replaces existing LRU caches with LFU caches (used calculating address statuses and reading address histories), as to have a better overall hit rate by better keeping the intersecting sets of historical txids that are in the histories for many addresses as they are used in new txs in mempool/blocks. With the new cache type the `--cache_all_tx_hashes` setting is no longer needed to quickly keep up mempool and new blocks with `--index_address_statuses`, this saves quite a bit of memory for similar performance, down from ~15gb to ~6gb. With the scribe default `--history_tx_cache_size` of 4194304 the cache will have an average hit rate of ~88%, going to 98-100% during load spikes, which gives it close enough performance to having the list of items being cached entirely stored in memory, but for less resources needed.
jeffreypicard (Migrated from github.com) reviewed 2022-07-29 15:48:44 +02:00
shyba (Migrated from github.com) approved these changes 2022-07-29 23:22:52 +02:00
shyba (Migrated from github.com) left a comment

Looks good. I would just consider using a deque instead of adding a linked list implementation.

Looks good. I would just consider using a `deque` instead of adding a linked list implementation.
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#65
No description provided.