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

问题描述

序言：

我最近对Entity Framework进行了大量的研究，而不断困扰我的事情是它的性能，当查询不加热时，所谓的冷查询。

我浏览了实体框架5.0的性能考虑文章。作者介绍了 Warm 和 Cold 查询的概念，以及它们的区别，我也注意到自己不知道它们的存在。这里可能值得一提的是我只有六个月的经验背后。

现在我知道我可以研究的主题，如果我想了解更好的框架在性能方面。不幸的是，互联网上的大部分信息都是过时的或主观的，因此我无法在 查询主题中查找任何其他信息。

到目前为止，我注意到的是，无论何时重新编译或重新点击，我的初始查询都变得非常缓慢。我们将迁移到Windows Server 2012，IIS8和SQL Server 2012中。我们将迁移到Windows Server 2012，IIS8和SQL Server 2012作为一个初中，我其实赢得了自己的机会，在休息之前测试他们。我很高兴他们介绍了一个预热模块，这将使我的应用程序准备好第一个请求。但是，我不知道如何继续升温我的实体框架。

我已经知道值得做的：

• 按照建议提前生成视图。


• 最终将我的模型移动到单独的程序集中。






我认为做什么，通常常常，可能是错误的方法：






• 在应用程序启动时执行虚拟数据读取，以便加快
  的加载，生成和验证模型。






问题：






• 在我的实体框架上可以获得高可用性的最佳方法是任何时候？


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





解决方案


<在任何时候，在实体框架上可以获得高可用性的最佳方法是什么？





您可以将预生成的视图和静态编译查询。





静态 CompiledQuerys 很好，因为它们可以快速而易于编写，并有助于降低性能。然而使用EF5，没有必要编译所有的查询，因为EF会自动编译查询本身。唯一的问题是，当缓存被扫描时，这些查询可能会丢失。因此，您仍然希望对那些仅发生非常罕见但已经很贵的编译查询保留引用。如果将这些查询放入静态类中，则会在首次需要时对它们进行编译。对于某些查询来说，这可能太晚了，因此您可能需要在应用程序启动期间强制这些查询的编译。





您提到的其他可能性是预生成的视图。特别是对于那些需要很长时间才能编译而不改变的查询。这样，您将性能开销从运行时转移到编译时间。这也不会引起任何滞后。但是，这个变化当然是通过数据库进行的，所以处理起来并不容易。代码更灵活。





不要使用很多TPT继承（这是EF中的一般性能问题）。建立你的继承层次太深也不太广泛。只有2-3个特定于某些类的属性可能不足以要求自己的类型，但可以作为现有类型的可选（可空）属性来处理。





Don不要长期坚持一个单一的环境。每个上下文实例都有自己的第一级高速缓存，随着性能的增长而减慢。上下文创建价格便宜，但上下文缓存实体内的状态管理可能变得昂贵。其他缓存（查询计划和元数据）在上下文之间共享，并将与AppDomain一起死亡。





所有这些都应该确保频繁地分配上下文并使用它们只需很短时间即可快速启动应用程序，即可编译很少使用的查询，并为经常使用的性能关键字查询提供预生成的视图。






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






基本上，每次丢失AppDomain。 IIS会每次 29小时，所以你永远不能保证你会有你的实例。也经过一段时间没有活动，AppDomain也被关闭。你应该尝试再来一次。也许您可以异步执行一些初始化（但要注意多线程问题）。在没有要求防止AppDomain死机的时候，您可以使用在应用程序中调用虚拟页面的计划任务，但最终会出现这种情况。





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




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

Preface:

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.

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 month of experience behind my back.

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 in, my initial queries are getting very slow. Any subsequent data read is fast (subjective), as expected.

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:

• Generate my Views in advance as suggested.
• Eventually move my models into a separate assembly.

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

• Doing dummy data reads at Application Start in order to warm things up, generate and validate the models.

Questions:

• What would be the best approach to have high availability on my Entity Framework at anytime?
• In what cases does the Entity Framework gets "cold" again? (Recompilation, Recycling, IIS Restart etc.)

解决方案

• What would be the best approach to have high availability on my Entity Framework at anytime?

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

Static CompiledQuerys are good because they're quick and easy to write and help reduce 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.

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.

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.

• In what cases does the Entity Framework gets "cold" again? (Recompilation, Recycling, IIS Restart etc.)

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屋！