实体框架和并行(Entity Framework and Parallelism)

背景

我有一个接收周期数据转储（XML文件），然后导入到使用实体框架5（代码优先）现有数据库的应用程序。 进口通过EF5而不是说BULK INSERT或BCP是因为已经在实体存在的业务规则必须应用。

处理似乎是CPU在应用程序本身的约束（的速度极快，写高速缓存启用磁盘IO子系统显示整个过程几乎为零盘等待时间，和SQL Server显示不超过8％-10％的CPU时间）。

为了提高效率，我建了一个使用TPL数据流管道与组件：

Read & Parse XML file
        |
        V
Create entities from XML Node
        |
        V
Batch entities (BatchBlock, currently n=200)
        |
        V
Create new DbContext / insert batched entities / ctx.SaveChanges()

我看到这样的性能大幅提高，但不能得到上述约60％的CPU。

分析

怀疑某种资源争用的，我跑使用VS2012 Profiler的资源争用数据（并发）模式的过程。

探查表明了我52％争标手柄2的资源。 钻井，我看到2手柄打造最争的方法是

System.Data.Entity.Internal.InternalContext.SaveChanges()

排在第二位，在40％左右为许多争论的SaveChanges为（），是

System.Data.Entity.DbSet`1.Add(!0)

问题

• 我怎样才能找出手柄2真的是（如第三方物流的一部分，EF的一部分）？
• 请问EF油门调用的DbContext实例从单独的线程分开？ 似乎有他们竞争共享资源。
• 有什么我可以做些什么来改善这种情况下并行？

UPDATE

对于有问题的运行，为调用的SaveChanges设置为12任务的最大并行度（我尝试过各种价值观，包括在以前运行无界）。

更新2

微软的EF团队提供反馈。 看到我的总结答案。

Answer 1:

下面总结我的实体框架团队在这个问题上的互动。 如果有更多的信息可用我会更新的答案

• 这个问题可以在微软重现。
• 手柄争关系到网络I / O（即使在本地主机上的SQL Server）。 具体而言，是用于网络I /在System.Data.dll中澳读缓冲器争用。
• 该EF小组目前正在与SQL连接团队合作，以更好地理解这个问题。
• 到目前为止，尚未从微软如何降低这种竞争的影响没有指导。

UPDATE

这个问题目前正在跟踪CodePlex上：

http://entityframework.codeplex.com/workitem/636?PendingVoteId=636

文章来源: Entity Framework and Parallelism