Use LFU caches for address status and history calculation in scribe and herald #65
No reviewers
Labels
No labels
area: database
area: documentation
area: elasticsearch
area: herald
area: packaging
area: scribe
consider soon
critical
dependencies
good first issue
hacktoberfest
help wanted
improvement
needs: repro
new feature
priority: blocker
priority: high
priority: low
priority: medium
type: bug
type: bug-fix
type: discussion
type: feature request
type: improvement
type: new feature
type: refactor
type: task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/hub#65
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lfu-cache"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.Looks good. I would just consider using a
deque
instead of adding a linked list implementation.