实体框架是否存在特定的性能问题？ GUID PK？
我的公司有一个基本的SOA，使用实体框架进行数据库访问。我们的一项服务必须与旧数据库交互，该数据库使用数据库中的uniqueidentifier主键。在单元和集成测试期间性能良好。
但是，在负载下，受影响的服务开始产生积压的排队请求。可以通过删除使用实体框架通过 uniqueidentifier PK 匹配行的代码部分来消除此队列。然后，服务再次变得高性能，使用相同的 ObjectContext，作为相同例程的一部分按整数 PK 匹配行。
数据库表在被其设计用途的遗留应用程序查询时表现良好。因此，我不认为这个问题与数据库/索引内的碎片有关。
在所示的代码示例中，domain 是一个 Entity Framework ObjectContext，MetaSetting 与映射的 EntityObject 相关，match.ObjectId 是一个 Guid。
metaSettings = domain.MetaSetting.Where(
ms => ms.AppUID.Equals(match.ObjectId)
).ToList();
My company has a basic SOA, using Entity Framework for database access. One of our services must interface with a legacy database which uses uniqueidentifier primary keys in the database. Performance is good during unit and integration testing.
However, under load, the affected service starts to produce a backlog of queued requests. This queue can be eliminated by removing the code sections which use Entity Framework to match rows by uniqueidentifier PK. The service then becomes performant again, matching rows by integer PK as part of the same routines, using the same ObjectContext.
The database table performs well being queried by the legacy application which it was designed for. I therefore do not believe this problem to be related to fragmentation within the database/index.
In the code sample shown, domain is an Entity Framework ObjectContext, MetaSetting relates to the mapped EntityObject and match.ObjectId is a Guid.
metaSettings = domain.MetaSetting.Where(
ms => ms.AppUID.Equals(match.ObjectId)
).ToList();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用Profiler
您是否检查过使用Profiler发送到服务器的TSQL？查明获取数据时发生的任何 TSQL 瓶颈将变得更加容易。
但看看您的代码，这个简单的 LINQ 应该与直接调用数据库一样高效。虽然 EF 执行转换会产生一些开销，但应该很小，因为您要将单个记录转换为单个对象实例。
使用 Include() 调用时会遇到问题，因为这些可能会使 TSQL 脚本膨胀并使其瘫痪。当 *:1 导航属性转换为
LEFT OUTER JOIN而不是INNER时，我遇到了问题。Use Profiler
Have you checked TSQL sent to the server using Profiler? It will be much easier to pinpoint any TSQL bottlenecks that happen while getting data.
But looking at your code this simple LINQ should be just as performant as a direct call to the DB. There is some overhead by EF though to do the transformation but it should be minor since you're transforming a single record to a single object instance.
You will run into problems when using Include() calls, because those may bloat TSQL script and cripple it down. I've had issues with it when a *:1 navigation property translated to
LEFT OUTER JOINinstead of anINNERone.