我们注意到一些非常小的网络服务调用花费的时间比我们预期的要长得多。我们做了一些调查并放置了一些计时器，我们将其缩小到创建我们的 Entity Framework 6 DbContext 的实例。不是查询本身，只是上下文的创建。从那以后，我进行了一些日志记录，以查看创建 DbContext 的实例实际实际花费的平均时间，似乎大约是 50 毫秒。

应用程序预热后，上下文创建速度并不慢。应用程序回收后，它从 2-4 毫秒开始(这是我们在开发环境中看到的)。随着时间的推移，上下文创建似乎变慢了。在接下来的几个小时内，它将爬升到 50-80 毫秒的范围并趋于平稳。

我们的上下文是一个相当大的代码优先上下文，包含大约 300 个实体 - 包括一些实体之间的一些非常复杂的关系。我们正在运行 EF 6.1.3。我们正在执行“每个请求一个上下文”，但对于我们的大多数 Web API 调用，它只执行一个或两个查询。创建上下文需要 60+ms，然后执行 1ms 查询有点不满意。我们每分钟大约有 10k 个请求，因此我们不是一个经常使用的网站。

这是我们所看到的快照。时代在 MS 中，大跌是回收应用程序域的部署。每行是 4 个不同的 Web 服务器之一。请注意，它也不总是同一台服务器。

我确实进行了内存转储以尝试充实正在发生的事情，这是堆统计信息:

00007ffadddd1d60    70821      2266272 System.Reflection.Emit.GenericFieldInfo
00007ffae02e88a8    29885      2390800 System.Linq.Enumerable+WhereSelectListIterator`2[[NewRelic.Agent.Core.WireModels.MetricDataWireModel, NewRelic.Agent.Core],[System.Single, mscorlib]]
00007ffadda7c1a0     1462      2654992 System.Collections.Concurrent.ConcurrentDictionary`2+Node[[System.Object, mscorlib],[System.Object, mscorlib]][]
00007ffadd4eccf8    83298      2715168 System.RuntimeType[]
00007ffadd4e37c8    24667      2762704 System.Reflection.Emit.DynamicMethod
00007ffadd573180    30013      3121352 System.Web.Caching.CacheEntry
00007ffadd2dc5b8    35089      3348512 System.String[]
00007ffadd6734b8    35233      3382368 System.RuntimeMethodInfoStub
00007ffadddbf0a0    24667      3749384 System.Reflection.Emit.DynamicILGenerator
00007ffae04491d8    67611      4327104 System.Data.Entity.Core.Metadata.Edm.MetadataProperty
00007ffadd4edaf0    57264      4581120 System.Signature
00007ffadd4dfa18   204161      4899864 System.RuntimeMethodHandle
00007ffadd4ee2c0    41900      5028000 System.Reflection.RuntimeParameterInfo
00007ffae0c9e990    21560      5346880 System.Data.SqlClient._SqlMetaData
00007ffae0442398    79504      5724288 System.Data.Entity.Core.Metadata.Edm.TypeUsage
00007ffadd432898    88807      8685476 System.Int32[]
00007ffadd433868     9985      9560880 System.Collections.Hashtable+bucket[]
00007ffadd4e3160    92105     10315760 System.Reflection.RuntimeMethodInfo
00007ffadd266668   493622     11846928 System.Object
00007ffadd2dc770    33965     16336068 System.Char[]
00007ffadd26bff8   121618     17335832 System.Object[]
00007ffadd2df8c0   168529     68677312 System.Byte[]
00007ffadd2d4d08   581057    127721734 System.String
0000019cf59e37d0   166894    143731666      Free
Total 5529765 objects
Fragmented blocks larger than 0.5 MB:
            Addr     Size      Followed by
0000019ef63f2140    2.9MB 0000019ef66cfb40 Free
0000019f36614dc8    2.8MB 0000019f368d6670 System.Data.Entity.Core.Query.InternalTrees.SimpleColumnMap[]
0000019f764817f8    0.8MB 0000019f76550768 Free
0000019fb63a9ca8    0.6MB 0000019fb644eb38 System.Data.Entity.Core.Common.Utils.Set`1[[System.Data.Entity.Core.Metadata.Edm.EntitySet, EntityFramework]]
000001a0f6449328    0.7MB 000001a0f64f9b48 System.String
000001a0f65e35e8    0.5MB 000001a0f666e2a0 System.Collections.Hashtable+bucket[]
000001a1764e8ae0    0.7MB 000001a17659d050 System.RuntimeMethodHandle
000001a3b6430fd8    0.8MB 000001a3b6501aa0 Free
000001a4f62c05c8    0.7MB 000001a4f636e8a8 Free
000001a6762e2300    0.6MB 000001a676372c38 System.String
000001a7761b5650    0.6MB 000001a776259598 System.String
000001a8763c4bc0    2.3MB 000001a8766083a8 System.String
000001a876686f48    1.4MB 000001a8767f9178 System.String
000001a9f62adc90    0.7MB 000001a9f63653c0 System.String
000001aa362b8220    0.6MB 000001aa36358798 Free

这似乎是相当多的元数据和类型用法。

我们尝试过的事情:

1. 创建要复制的简单测试工具。它失败了，我猜是因为我们没有改变流量，或者改变运行的查询类型。仅仅加载上下文并一遍又一遍地执行几个查询并不会导致时间增加。
2. 我们显着减少了上下文，之前是 500 个实体，现在是 300 个。速度没有任何变化。我的猜测是因为我们根本没有使用那 200 个实体。
3. (编辑)我们使用 SimpleInjector 来创建我们的“每个请求的上下文”。为了验证它不是 SimpleInjector，我通过 new'in 启动了一个 Context 实例。同样缓慢的创建时间。
4. (编辑)我们已经生成了 EF。没有造成任何影响。

我们可以进一步调查什么？我知道 EF 使用的缓存很大，可以加快速度。缓存中有更多东西会减慢上下文创建速度吗？有没有一种方法可以准确地查看该缓存中的内容以充实其中的任何奇怪内容？有谁知道我们具体可以做什么来加速上下文创建？

更新 - 2017 年 5 月 30 日

我获取了 EF6 源代码并编译了我们自己的版本以坚持一些时间。我们经营着一个非常受欢迎的网站，因此收集大量时间信息很棘手，我没有达到我想要的程度，但基本上我们发现所有减速都来自 this method

public void ForceOSpaceLoadingForKnownEntityTypes()
    {
        if (!_oSpaceLoadingForced)
        {
            // Attempting to get o-space data for types that are not mapped is expensive so
            // only try to do it once.
            _oSpaceLoadingForced = true;

            Initialize();
            foreach (var set in _genericSets.Values.Union(_nonGenericSets.Values))
            {
                set.InternalSet.TryInitialize();
            }
        }
    }

foreach 的每次迭代都会命中我们上下文中 DBSet 定义的每个实体。每次迭代都相对较短 0.1-0.3 毫秒，但是当您添加我们拥有的 254 个实体时，它会加起来。我们仍然没有弄清楚为什么它一开始很快就变慢了。

最佳答案

这里是我开始解决问题的地方，而不是转向对企业更友好的解决方案。

Our context is a fairly large code-first context with around 300 entities 

虽然 EF 随着时间的推移有了很大的改进，但我仍然会开始认真考虑在你达到 100 个实体后切碎东西(实际上我会早于此开始，但这似乎是许多人所说的神奇数字 - 共识？)。将其视为为“上下文”设计，但使用“域”一词代替？这样你就可以向你的高管推销你正在应用“领域驱动设计”来修复应用程序？也许您正在为 future 的“微服务”进行设计，然后您在一个段落中使用了两个流行语。 ;-)

我不是企业领域 EF 的忠实粉丝，因此我倾向于避免在大规模或高性能应用程序中使用它。你的旅费可能会改变。对于 SMB，它可能完全没问题。不过，我确实遇到过使用它的客户。

我不确定以下想法是否完全最新，但根据经验，我会考虑其他一些事情。

• 预生成您的观点。它们是查询中最昂贵的部分。这将对大型模型有更大帮助。
• 将您的模型移到一个单独的装配体中。与其说是性能方面的问题，倒不如说是我在代码组织方面的一个小毛病。
• 检查您的应用程序、模型以了解缓存的可能性。查询计划缓存通常可以节省相当多的时间。
• 使用 CompileQuery。
• 在可行的情况下，使用 NoTracking。如果您不需要该功能，这将节省大量资金。

看起来您已经在应用程序上运行某种类型的探查器，所以我假设您还查看了 SQL 查询和可能的性能提升。是的，我知道这不是您要解决的问题，但从用户的角度来看，它可以促成整个问题。

针对@WiktorZichia 关于未回答有关性能问题的评论，在企业系统中消除此类问题的最佳方法是消除 Entity Framework 。每个决定都需要权衡取舍。 EF 是一个很好的抽象，可以加快开发速度。但它会带来一些不必要的开销，可能会大规模损害系统。现在，从技术上讲，我仍然没有回答“我如何按照我试图解决的方式解决这个问题”的问题，所以这可能仍然被视为失败。

关于c# - 创建 Entity Framework Context 的实例在负载下变慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43523374/