如何“热身"实体框架?什么时候“冷"? [英] How to "warm-up" Entity Framework? When does it get "cold"?

问题描述

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

No, the answer to my second question is not the winter.

前言:

我最近对实体框架进行了大量研究，一直困扰着我的是当查询未预热时的性能，即所谓的冷查询.

I've been doing a lot of research on Entity Framework recently and something that keeps bothering me is its performance when the queries are not warmed-up, so called cold queries.

我阅读了有关实体框架 5.0 的性能注意事项文章.作者介绍了Warm 和Cold 查询的概念以及它们的不同之处，我自己也注意到了，但并不知道它们的存在.这里可能值得一提的是，我只有六个月的经验.

I went through the performance considerations article for Entity Framework 5.0. The authors introduced the concept of Warm and Cold queries and how they differ, which I also noticed myself without knowing of their existence. Here it's probably worth to mention I only have six months of experience behind my back.

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

Now I know what topics I can research into additionally if I want to understand the framework better in terms of performance. Unfortunately most of the information on the Internet is outdated or bloated with subjectivity, hence my inability to find any additional information on the Warm vs Cold queries topic.

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

Basically what I've noticed so far is that whenever I have to recompile or the recycling hits, my initial queries are getting very slow. Any subsequent data read is fast (subjective), as expected.

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

We'll be migrating to Windows Server 2012, IIS8 and SQL Server 2012 and as a Junior I actually won myself the opportunity to test them before the rest. I'm very happy they introduced a warming-up module that will get my application ready for that first request. However, I'm not sure how to proceed with warming up my Entity Framework.

我已经知道的值得去做:

What I already know is worth doing:

• 按照建议提前生成我的观点.
• 最终将我的模型移动到一个单独的组件中.

我考虑做的事情，根据常识，可能是错误的做法:

What I consider doing, by going with common sense, probably wrong approach:

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

问题:

• 随时在我的实体框架上实现高可用性的最佳方法是什么?
• 在什么情况下实体框架会再次变冷"?(重新编译、回收、IIS 重启等)

推荐答案

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

您可以混合使用预生成视图和静态编译查询.

You can go for a mix of pregenerated views and static compiled queries.

静态 CompiledQuerys 很好，因为它们快速而简单编写并帮助提高性能.但是，对于 EF5，不需要编译所有查询，因为 EF 会自动编译查询本身.唯一的问题是，当缓存被清扫时，这些查询可能会丢失.因此，您仍然希望保留对您自己编译的查询的引用，这些查询仅发生在非常罕见但代价高昂的情况下.如果将这些查询放入静态类中，它们将在首次需要时进行编译.这对于某些查询来说可能为时已晚，因此您可能希望在应用程序启动期间强制编译这些查询.

Static CompiledQuerys are good because they're quick and easy to write and help increase performance. However with EF5 it isn't necessary to compile all your queries since EF will auto-compile queries itself. The only problem is that these queries can get lost when the cache is swept. So you still want to hold references to your own compiled queries for those that are occurring only very rare, but that are expensive. If you put those queries into static classes they will be compiled when they're first required. This may be too late for some queries, so you may want to force compilation of these queries during application startup.

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

Pregenerating views is the other possibility as you mention. Especially, for those queries that take very long to compile and that don't change. That way you move the performance overhead from runtime to compile time. Also this won't introduce any lag. But of course this change goes through to the database, so it's not so easy to deal with. Code is more flexible.

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

Do not use a lot of TPT inheritance (that's a general performance issue in EF). Neither build your inheritance hierarchies too deep nor too wide. Only 2-3 properties specific to some class may not be enough to require an own type, but could be handled as optional (nullable) properties to an existing type.

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

Don't hold on to a single context for a long time. Each context instance has its own first level cache which slows down the performance as it grows larger. Context creation is cheap, but the state management inside the cached entities of the context may become expensive. The other caches (query plan and metadata) are shared between contexts and will die together with the AppDomain.

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

All in all you should make sure to allocate contexts frequently and use them only for a short time, that you can start your application quickly, that you compile queries that are rarely used and provide pregenerated views for queries that are performance critical and often used.

• 在什么情况下实体框架会再次变冷"?(重新编译、回收、IIS 重启等)

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

Basically, every time you lose your AppDomain. IIS performs restarts every 29 hours, so you can never guarantee that you'll have your instances around. Also after some time without activity the AppDomain is also shut down. You should attempt to come up quickly again. Maybe you can do some of the initialization asynchronously (but beware of multi-threading issues). You can use scheduled tasks that call dummy pages in your application during times when there are no requests to prevent the AppDomain from dying, but it will eventually.

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

I also assume when you change your config file or change the assemblies there's going to be a restart.

这篇关于如何“热身"实体框架?什么时候“冷"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！