wpf操作缓存示例_缓存性能回火的示例

wpf操作缓存示例

在2015年，缓存常用数据可能会提高应用程序性能的人不会感到惊讶。 广泛使用的技术是在JVM内部本地缓存某些数据结构，而不是通过来自外部存储的远程调用来请求它们。

在应用程序中引入此类缓存可能会在延迟和吞吐量方面提高应用程序的性能 。 但是和往常一样，这个世界上没有免费的午餐。 在本文中，我们将探讨在将此类缓存引入您的应用程序时犯下的两个最常见的错误。

这些潜在问题中的第一个与性能优化的另一个方面有关，即容量 。 向您的应用程序引入缓存将需要为同一应用程序提供更多的内存。 除了增加基础架构成本之外，这还可能带来其他负面影响，首先是垃圾收集过程必须做更多的工作才能遍历内存中的数据结构。

结果，就平均或平均延迟而言，该应用程序可能会显示出更好的性能，但是某些操作的最坏情况延迟可能会变得比以前更糟。 试想一下， GC算法现在必须遍历额外的千兆字节的缓存数据结构，以检测未使用的对象。

为了减少此问题的影响，您应该首先监视缓存的利用率 。 利用率是根据缓存中实际使用的对象的百分比来衡量的。 就像人们可能猜到的那样，高利用率（在90年代高）是精心设计的缓存的标志。 另一方面，利用率低则表明您正在将内容加载到永不使用的内存中。

为了理解这个概念，让我们检查一下一种假设情况，其中经常使用有关人的信息，例如其姓名，社会保险号和出生地。 如果考虑到人们在真实世界中实际更改其姓名或生日的频率，那么这些人可能几乎是一成不变的。 对于您的应用程序中的此类对象，您可以并且可能应该引入缓存，以确保仅从外部存储加载一次此类Person。

填充此类缓存的一种方法是将外部存储所拥有的所有人员急切地加载到本地缓存中。 当外部环境包含美国的全部人口时，您最终将获得一个包含300M Persons的缓存。 另一方面，如果您的应用程序被设计为仅由犹他州的居民使用，人口仅不到3M，那么您会很快注意到缓存利用率极低，正在使用的缓存条目不到1％ 。

在缓存利用率方面具有这种透明度，可以帮助您发现预留空间过大。 有了这样的洞察力，您就可以开始缩小缓存的大小，从而减少内存消耗和GC算法的负担。

当使用某些缓存算法部署配置不足的缓存时，就会暴露出缓存解决方案倾向于引入的第二种甚至更危险的情况。 在这种情况下，您的应用程序会遇到称为“ 快速周转率”或“ 垃圾回收”的概念。 无论名称是什么，当不断清除缓存的内容并再次读取时，该概念就会露出丑陋的头。

快速周转率的概念再次通过示例得到最好的解释。 让我们考虑一下在应用程序中内置人员缓存的情况。 让我们将解决方案推广到由3亿多人组成的美国整个人口，而不是在犹他州进行部署。 但是，让我们使用对犹他州来说效果很好的相同缓存大小，并将最大缓存大小保留为3M个元素。 另外，让我们延迟加载缓存，并使用LRU处理关于缓存未命中的逐出负载策略。

启动应用程序将开始填充缓存，因为应用程序正在使用不同的人员。 监视缓存表明，前3M条目很快就被填满。 但是，由于我们的应用程序需要300M +个人的详细信息，因此我们继续收到对仍未缓存的个人的请求，从而触发缓存未命中。 然后，这些高速缓存未命中会触发外部资源来加载更多的人，这些人也希望在已经充满的高速缓存中占有一席之地。 现在，LRU策略开始执行，并从缓存中弹出一些对象，从而为要加载的新对象腾出空间。

不幸的是，此过程永远不会停止–缓存太小而无法对应用程序有利。 到达的新业务交易不断发现，在约99％的情况下，请求的人不在高速缓存中，从而触发了高速缓存未命中，并对高速缓存又产生了另一次逐出负载。 在这种情况下，高速缓存可能弊大于利。 如果高速缓存的周转速度比现有高速缓存条目的使用速度快，则使用这种高速缓存的应用程序实际上会更慢 。 再次造成这种情况的原因之一是垃圾收集面临的额外压力，在这种情况下， 垃圾收集承担了很多额外的负担。

因此，除了监视缓存利用率之外，您还应注意缓存命中率和可能由缓存未命中引发的周转率。 注意高级别的缓存未命中可能会浮现出颠簸的根本原因。

希望一些读者将来能够逃脱这种陷阱。 Plumbr代理尚无法在缓存使用方面监视JVM，但是我们在该领域进行了许多有趣的研究。 请继续关注新闻！

翻译自: https://www.javacodegeeks.com/2015/08/examples-of-caching-backfiring-on-performance.html

wpf操作缓存示例