Klaytn State Trie Cache Series #2: Searching for the Optimal Cache
See the list of articles here.
🇰🇷: Klaytn State Trie Cache Series #2: 최적의 cache 찾기
Improving the blockchain platform has always been one of Klaytn’s priorities. In this series of articles, we would like to walk you through the journey of improving the performance of the state trie cache.
- Identifying the Cache Problem
- Searching for the Optimal Cache
- Calculating State Trie Cache Miss
- Tuning Cache Size
In our previous post, we learned that the excessive memory use had been due to a prolonged allocation of a large heap. There are other Go cache options with less GC overhead such as Fastcache or Freecache. In this post, we will introduce some ways to find a less memory-consuming cache.
The above article cites Ristretto, Bigcache, Freecache, and Fastcache as Go caches with high performance. To test their suitability on Klaytn, we tried them out and here are the results:
KLAY Transfer Test
AWS instance : m5.2xlarge
CN 4, PN 4, EN 4, locust slave 4
Memory size : 32G
Cache size : 6G
RPS 2000, accounts : 0.5M
- Total memory usage refers to the total memory used, including GC.
- The number of saved entries is derived from the stat from each cache.
Bigcache is the cache originally in use.
Ristretto is based on the LFU (Least Frequently Used) algorithm, meaning that it tracks and manages the frequency rather than how recent the entry has been called. It uses a lot of memory to maintain each data’s call occurrences, which may have been the reason for the out of memory. And, judging by the numerous cache misses, it presumably doesn’t save that many entries compared to other caches.
This unexpected result of Ristretto is not only limited to Klaytn. According to the benchmark by CODASYL, the hit ratio is unmistakably low compared to other caches. This is due to the fact that the suitability of LRU or LFU varies depending on the data input method. When we think of how state tries are created on Klaytn, LRU seems to be more suitable, since having access to the latest nodes is the necessary procedure to create a new trie. Accordingly, despite the best performance shown by Ristretto on the throughput chart above, it recorded the highest number of cache misses in Klaytn’s case.
In short, since Ristretto demonstrated a lower performance compared to other caches, it was determined to be not suitable for Klaytn.
Freecache is said to have a new structure, which gets rid of the GC overhead. It has less memory usage than Bigcache and can store more entries.
Fastcache shares the same structure with Bigcache, but is developed in a little more efficient way. It also uses less memory compared to Bigcache, while storing more entries.
Freecache and Fastcache have the same number of entries, but the memory usage shows a big difference. Therefore, Fastcache, with the least memory usage and most entries, was selected as Klaytn’s new cache.
To find out how better Fastcache performed compared to Bigcache, we ran another TPS test with larger instances. We tested different caches on identical instance types.
KLAY Transfer Test
AWS instance : m5.18xlarge
CN 4, PN 8, EN 8, locust slave 4
Memory size : 144G
RPS 4000, accounts : 5M
We saw that the memory usage has been reduced by 30%, from 98 G to 69 G, and the number of saved entries has increased by 12%, from 147 M to 165 M.
To check if the speed has improved, we also ran the Cypress sync test. Notice the difference in sync speed due to cache misses for the smaller instance cache.
Cypress sync test
AWS instance : m5.2xlarge
Memory size : 32G
Cache : Bigcache, Fastcache
Cache Size : 6GB, 9GB
The results on the left graph show that Fastcache saves more entries than Bigcache. The occurrence of cache misses has been reduced and the appearance of the first cache miss has also been delayed. And the right graph shows the current block numbers, whereby Fastcache has a higher block number than Bigcache. This means that the synchronization of Cypress block data is carried out faster by Fastcache than Bigcache.
In this post we looked into three alternatives to Bigcache and finally came to the conclusion that Fastcache is indeed a better choice than Bigcache, in terms of both memory management and performance. Fastcache has been applied on Klaytn from v1.5.0 or higher, so if you are still running your node on a lower version, we recommend you get an update.
We hope that this post is helpful in selecting an optimal cache. Next time, we will look at some factors that influence state trie cache misses. Stay tuned!
