Add LRU cache for eth block data and transactions statuses#479
Add LRU cache for eth block data and transactions statuses#479sorpaas merged 4 commits intopolkadot-evm:masterfrom
Conversation
client/rpc/src/eth.rs
Outdated
| /// Storing them in an LRU cache will allow to reduce database accesses | ||
| /// when many subsequent requests are related to the same blocks. | ||
| pub struct EthBlockDataCache<B: BlockT> { | ||
| blocks: Mutex<LruCache<B::Hash, EthereumBlock>>, |
There was a problem hiding this comment.
Please change all Mutex usage in this file to parking_lot::Mutex. Might also require you to change some unrelated code.
There was a problem hiding this comment.
Also, isn't it better if we use RwLock here?
There was a problem hiding this comment.
I see a few other std Mutex. If parking_lot is better, it would be a good follow-up PR to migrate all Mutex to parking_lot then ? I'll change only those new Mutex for the parking_lot version in this PR.
There was a problem hiding this comment.
Can you also change it to RwLock? Or what are the reasons not to?
There was a problem hiding this comment.
Since it's an LRU Cache get also take an &mut self since it'll bump the entry to the top of the cache.
|
Can you fix rustfmt? |
…evm#479) * add lru cache for eth block data and transactions statuses * use parking_lot::Mutex * cargo fmt
When calling RPC (mainly related to logs) a lot of time is spent fetching the data from the database.
This PR adds an LRU cache to avoid reaching the database when many requests are related to the same block (this happen a lot with block explorers).
The cache use the substrate block hash as a key, as it won't change in case of reorg (instead of block id/height).
Followups / alternatives
If those RPC were converted to async a background task could manage the actual caching and access to the database, and would send the data back to the request handler through an async oneshot channel. If doing this async convertion is acceptable then I'll work on implementing it.