如何“热身”实体框架？什么时候变“冷”？

Question

不，我第二个问题的答案不是冬天。

前言：

我最近对Entity Framework进行了很多研究，而令我困扰的是查询未预热时的性能，即所谓的冷查询。

我浏览了关于Entity Framework 5.0 的性能注意事项文章。作者介绍了“ 热”和“ 冷”查询的概念以及它们之间的区别，我也注意到自己而并不知道它们的存在。在这里可能值得一提的是，我只有六个月的经验。

现在，我知道如果我想从性能方面更好地理解框架，我可以进一步研究哪些主题。不幸的是，Internet上的大多数信息已经过时或过分带有主观性，因此，我无法找到有关“ 热与冷”查询主题的任何其他信息。

到目前为止，基本上我注意到的是，每当我需要重新编译或回收命中时，我的初始查询就会变得非常缓慢。如预期的那样，任何后续数据读取都是快速的（主观的）。

我们将迁移到Windows Server 2012，IIS8和SQL Server 2012，作为一名初级学生，我实际上赢得了自己在其余测试之前进行测试的机会。我很高兴他们引入了一个预热模块，该模块可以使我的应用程序为第一个请求做好准备。但是，我不确定如何继续预热我的实体框架。

我已经知道值得做的事情：

根据建议提前生成我的视图。

最终将模型移到单独的装配中。

我认为，按照常识，可能做错了什么：

在应用程序启动时读取虚拟数据，以预热，生成和验证模型。

问题：

何时在我的实体框架上实现高可用性的最佳方法是什么？

在什么情况下，实体框架会再次变得“冷”？（重新编译，回收，IIS重新启动等）

Answer 1

如果您希望在所有通话中获得最佳性能，则应仔细考虑您的体系结构。例如，当应用程序加载时，将经常使用的查询预先缓存在服务器RAM中可能是有意义的，而不是对每个请求都使用数据库调用。该技术将确保对常用数据的最小应用程序响应时间。但是，您必须确保具有行为良好的到期策略，或者在进行任何会影响缓存数据的更改时始终清除缓存，以避免并发问题。通常，您应该努力设计分布式体系结构，以便仅在本地缓存的信息过时或需要进行事务处理时才需要基于IO的数据请求。在内存缓存检索中，任何“在线”数据请求的检索时间通常比本地检索时间长10-1000倍。仅凭这一事实，与“本地与远程”数据问题相比，有关“冷数据与热数据”的讨论就显得无关紧要了。

Answer 2

一般提示。执行严格的日志记录，包括访问内容和请求时间。初始化应用程序以热启动从上一步中拾取的非常慢的请求时，请执行虚拟请求。除非存在实际问题，否则不要费心进行优化，与应用程序的使用者进行交流并提出要求。如果只是想找出需要优化的内容，就可以轻松拥有一个连续的反馈循环。现在来解释为什么虚拟请求不是错误的方法。降低复杂性 -您正在以一种可以在不更改框架的情况下运行的方式对应用程序进行预热，并且无需弄清楚可能的时髦API /框架内部结构就可以正确地进行操作。更大的覆盖范围 -您正在立即对与缓慢请求有关的所有缓存层进行预热。解释高速缓存何时“冷”。这种情况发生在您框架中应用缓存的任何层，性能页顶部有一个很好的描述。每当在可能使缓存失效的潜在更改之后必须验证缓存时，这可能是超时或更智能的（即，缓存项的更改）。逐出缓存项时，链接的性能文章中的“缓存逐出算法”部分对此进行了描述，但总而言之。LFRU（最不常用-最近使用）缓存命中次数和年龄，限制为800个项目。您提到的其他内容（特别是重新编译和重新启动IIS）会清除部分或全部内存缓存。