EF 预编译视图和自定义查询

本文关键字：自定义 查询 视图 编译 EF | 更新日期: 2023-09-27 17:56:18

我正在尝试增加 EF 查询的"首次调用"执行时间，并发现可以将预编译视图用于查询。使用VS库中名为"EF Code First 预生成视图生成器"的 VS 库中名为"EF Code First 预生成视图生成器"生成预编译视图后，我没有注意到我的一些繁重查询（使用包含和联接）有任何性能提升。

然后我尝试调查 t4 模板生成的代码。我看到有一个从DbMappingViewCache下降的类，它通过其方法GetView(EntitySetBase extent)返回请求的DbMappingView。

看起来所有这些视图仅用于简单查询，所以我问自己是否有任何方法可以在预编译阶段为我的特定繁重查询缓存视图。有谁知道如何实现这一目标？可能吗？

EF 预编译视图和自定义查询

看看这篇博文，它讨论了减少启动时间的几种方法。

供参考：

  • 使用缓存的数据库模型存储

    这可能对启动性能影响最大，并且仅在使用代码优先模型时才需要。就启动时间而言，使用 Code First 管道构建和编译大型模型的成本非常高。此步骤将使用昂贵的 o-c 映射生成缓存代码优先管道，并将其存储在文件系统上的 xml 文件中。下次应用程序启动时，EF 将反序列化此缓存的映射文件，从而显著缩短启动时间。

  • 生成预编译视图：

    你已经在这样做了，但也要查看实体

    框架 6 的交互式预生成视图，它允许你预编译视图并缓存它们，而不会因生成时间的增加而陷入困境。

  • 使用 n 代生成实体框架的预编译版本以避免抖动

    实体框架不在 .net 框架的默认安装中。因此，默认情况下，EF 程序集不是 NGEN，这意味着每次应用程序启动时都需要对 EF 代码进行 JITED。由于 EF 是一个非常庞大且复杂的框架（实体框架程序集超过 5MB），并且即使对于简单的方案也需要大多数代码路径，因此 JITTING 对启动性能有明显的影响。

    针对 EF 运行 NGEN 就像在根终端会话中执行以下命令一样简单：

    %WINDIR%'Microsoft.NET'Framework'v4.0.30319'ngen install EntityFramework.dll

虽然与 EF 没有特别关系，但这里有一个技巧，通常应该适用于任何查询。这个想法是通过应用程序初始化模块预热您的应用程序。因此，在您的 web.config 中添加它将导致此模块向/startup路由发送请求以执行初始化。

<applicationInitialization
     doAppInitAfterRestart="true" >
   <add initializationPage="/startup" />
</applicationInitialization>

使用此视图 （ /startup ），可以为测试用户触发繁重的查询（假设它是只读的），这将导致 EF 执行所有启动初始化。

有关保持应用池始终运行的其他提示，请参阅此答案。

相关文章：