asp.net - 如何 "warm-up" Entity Framework ？什么时候得到 "cold"？

Question

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

前言:

我最近对 Entity Framework 做了很多研究，一直困扰我的是它在查询未预热时的性能，即所谓的冷查询。

我浏览了performance considerations Entity Framework 5.0 的文章。作者介绍了暖查询和冷查询的概念以及它们的区别，我自己也在不知道它们存在的情况下注意到了它们。在这里可能值得一提的是，我背后只有六个月的经验。

现在我知道如果我想在性能方面更好地了解框架，我可以额外研究哪些主题。不幸的是，互联网上的大多数信息都已经过时或主观性臃肿，因此我无法找到有关“热查询”与“冷查询”主题的任何其他信息。

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

我们将迁移到 Windows Server 2012、IIS8 和 SQL Server 2012，作为一名初级学生，我实际上为自己赢得了先于其他人测试它们的机会。我很高兴他们引入了一个预热模块，该模块将使我的应用程序为第一个请求做好准备。但是，我不确定如何继续预热我的 Entity Framework 。

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

• 按照建议提前生成我的观点。
• 最终将我的模型移至单独的装配体中。

我认为按照常识去做，可能是错误的方法:

• 在应用程序启动时读取虚拟数据以加热数据建立、生成并验证模型。

问题:

• 随时在 Entity Framework 上实现高可用性的最佳方法是什么？
• Entity Framework 在什么情况下会再次变得“冷”？ (重新编译、回收、IIS重启等)

Answer 1

• 随时在 Entity Framework 上实现高可用性的最佳方法是什么？

您可以混合使用预生成的 View 和静态编译的查询。

静态CompiledQuerys之所以好，是因为它们编写起来又快又容易，并且有助于提高性能。但是，对于 EF5，无需编译所有查询，因为 EF 会自动编译查询本身。唯一的问题是，当缓存被清除时，这些查询可能会丢失。因此，您仍然希望保留对您自己编译的查询的引用，这些查询只发生非常罕见，但代价高昂。如果您将这些查询放入静态类中，它们将在第一次需要时被编译。这对于某些查询来说可能为时已晚，因此您可能希望在应用程序启动期间强制编译这些查询。

正如您提到的，预生成 View 是另一种可能性。特别是对于那些需要很长时间才能编译并且不会改变的查询。这样您就可以将性能开销从运行时转移到编译时。而且这不会引入任何滞后。但当然这个变化会传递到数据库，所以处理起来并不那么容易。代码更加灵活。

不要使用大量 TPT 继承(这是 EF 中的一般性能问题)。继承层次结构既不要太深也不要太宽。仅特定于某个类的 2-3 个属性可能不足以需要自己的类型，但可以作为现有类型的可选(可为空)属性进行处理。

不要长时间坚持单一上下文。每个上下文实例都有自己的一级缓存，随着它变大，性能会降低。上下文创建很便宜，但上下文的缓存实体内的状态管理可能会变得昂贵。其他缓存(查询计划和元数据)在上下文之间共享，并将与 AppDomain 一起消亡。

总而言之，您应该确保频繁分配上下文并仅在短时间内使用它们，您可以快速启动应用程序，编译很少使用的查询，并为性能关键的查询提供预生成的 View ，并且经常使用。

• Entity Framework 在什么情况下会再次变得“冷”？ (重新编译、回收、IIS重启等)

基本上，每次您丢失 AppDomain 时。 IIS 每隔 29 hours 执行一次重新启动，因此您永远无法保证您会拥有实例。此外，一段时间没有事件后，AppDomain 也会关闭。你应该尝试再次快速上来。也许您可以异步执行一些初始化(但要注意多线程问题)。您可以使用计划任务，在没有请求时调用应用程序中的虚拟页面，以防止 AppDomain 死亡，但它最终会死亡。

我还假设当您更改配置文件或更改程序集时，将会重新启动。