szhbsd Klaytn为了提高区块链平台的性能，做了许多方面的努力。我们将通过下列文章介绍?state trie cache性能改善过程。
???确认Cache问题的原因
???寻找最佳的Cache
???计算State trie cache miss
???进行?Cache Size Tuning
在上一篇，我们假设造成cache miss的因素为state trie size(TotalAccounts、ActiveAccounts、TPS、trie node size)的变化和cache size，并通过测试进行确认。但是由于通过确认state trie size的变化，得出最佳的cache size是一件非常困难的事情，因此认为在既定的物理存储容量条件下，得出最佳的cache size，才是减少cache miss的可行方案。在本篇中，我们将探讨如何确认最佳的cache size。
下表是将Fastcache的cache size设定为与原来的Bigcache相同的值得出的结果(tuning前)以及给fastcache的cache size留有余量后得出的结果(tuning后)。我们通过测试得到了等同于Bigcache?memory余量的cache size，并将其对应在Tuning上，即下表中的Tuning后的值。
上表中，Cache size是设定值，memory使用量和memory余量是测定值。
在进行以上测试后，我们按照Fastcache的大小，对physical memory进行scaling，自动分配cache size。Scaling算法如下：
if physicalMemMB < 20 * 1024 {
cacheSizeMB := 1 * 1024
} else if physicalMemMB < 100 * 1024 {
cacheSizeMB := physicalMemMB * 0.3
} else {
cacheSizeMB := physicalMemMB * 0.35
}
当内存大小低于20G时，为了保留约10G的余量，将cache size固定为1G。当内存大于20G、低于100G时，将占有物理内存的30%，以m5.2xlarge为准，拥有10G的余量。当内存大小大于100G时，将占有物理内存的35%，以c5.18xlarge为准，拥有44.5G的余量。
以上测试均在存在大量账户的条件下进行，所以就算分配了更多的内存，不会对系统运行造成影响。但是如果启用计算量大的API或contract，内存使用量将会增加，因此我们为了防止OOM的出现，设定了足够的余量。
[参考事项]?Klaytn服务器建议使用m5.2xlarge。
通过Scaling logic给Fastcache分配cache size时，被分配的fastcache size如上表。上表中的数值基于足够高的TPS和存在大量account的条件下测定的量，因此在实际操作中，内存使用量可能会低于上表中的数值。为了更快更稳定地操作，也可以通过klaytn执行?flag增加fastcache的size，但可能会出现内存不足，因此需要谨慎使用。
本系列文章介绍了通过Klaytn State Trie Cache Series提高state trie cache的过程。我们发现了Klaytn使用的cache中存在的问题，找到了可替代的cache。然后分析了造成state trie cache中cache miss的原因，通过测试进行验证，并为了在既定的physical内存条件下找到合适的cache size，进行了cache size tuning。
以上就是提高state trie cache的全部过程。若对Klaytn state trie cache存在疑问，欢迎大家在Klaytn论坛（https://forum.klaytn.com/）提问。谢谢大家。
关于Klaytn
项目名称: Klaytn
英文缩写: KLAY
官方网站: https://www.klaytn.com/
项目简介：Klaytn是以服务为中心的企业级分布式信任区块链平台，通过高效的“混合”设计，结合了公有链（分布式数据和控制、分布式治理）和私有链（低延迟、高可扩展性）的最优功能。Klaytn与全球众多知名品牌的参与合作，通过共同的不懈努力，创建可靠的去中心化业务平台。Klaytn治理委员会是一个由跨国企业和组织组成的联盟，负责运营共识节点网络，推动生态系统发展。Kakao 的区块链开发部门「Ground X」已正式推出 Klaytn，并可用于商业用途。
