数据访问的性能和可扩展性 [关闭]答案

【问题标题】：Performance and scaleability for data access [closed]数据访问的性能和可扩展性 [关闭]
【发布时间】：2012-01-31 07:54:54
【问题描述】：

我看了很多答案，但没有找到满意的答案。这是问题所在。我需要创建一个 Web 应用程序。技术将基于 Microsoft 堆栈（ASP.NET 4、C#、SQL Server 2008）。基础设施将托管在 Amazon EC2 上。我需要决定访问数据的最佳方式。

实体框架
平面老ADO.NET

在高峰期，一次可以有大约 100,000 人访问此网站。为了达到这个规模并获得不错的性能，可以使用实体框架还是更好地依赖 ADO.NET？ Entity framework Vs ADO.NET 是否存在性能问题？

任何提示都会有所帮助。

【问题讨论】：

标签： asp.net performance entity-framework ado.net scalability

【解决方案1】：

由于您正在构建高流量网站，您可能应该使用简单的 Ado.net。但是 Micro-ORM 可以成为您的一个选择。例如 SO 使用单个文件 ORM dapper dot net。如果您查看 Performce 表，您将看到 EntityFramework 不应该是一个选项。我个人喜欢 PetaPoco。

http://code.google.com/p/dapper-dot-net/

http://samsaffron.com/archive/2011/03/30/How+I+learned+to+stop+worrying+and+write+my+own+ORM

 **Method**                                     **Duration**     
 Hand coded (using a SqlDataReader)         47ms 
 Dapper ExecuteMapperQuery<Post>            49ms 
 ServiceStack.OrmLite (QueryById)           50ms 
 PetaPoco                                   52ms    Can be faster 
 BLToolkit                                  80ms 
 SubSonic CodingHorror                      107ms 
 NHibernate SQL                             104ms 
 Linq 2 SQL ExecuteQuery                    181ms 
 Entity framework ExecuteStoreQuery         631ms

【讨论】：

谢谢大家。这很有帮助。我猜实体框架已经出来了。 O 正在研究 dapper。在一天结束时，我可能会依赖 ADP.NET。很伤心，因为我真的很喜欢 EF。但我想不能吃蛋糕也不能吃。
EF 对性能的最大影响之一是生成视图和准备查询。请参阅此处：msdn.microsoft.com/en-us/library/cc853327.aspx 也就是说，如果您查看有关此主题的更新信息，您会发现 .net 4.5 上的 EF5+ 通过自动编译所有查询来考虑这一点，从而显着提高性能。见这里：blogs.msdn.com/b/adonet/archive/2012/02/14/…。但是，您仍然可以通过更新到 4.5 或仅手动编译查询来获得对 EF4 的提升。

【解决方案2】：

实体框架、LINQ2SQL 和其他 OR 映射器在应用服务器端的运行时间损失很小。然而，在大多数实际应用中，惩罚远低于 1%。

与大多数技术（以不同的方式做同样的事情）一样，性能影响并不取决于技术，而是取决于您如何实现它们。如果您键入一个 EF 查询，该查询将转换为几个循环数据库的 SQL 查询，您可能会因 EF 失败而灾难性地失败。但这些情况很容易发现，也很容易解决。

【讨论】：

根据我的经验，对 EF、LINQ2SQL 和其他 ORM 的惩罚远高于 1% —— 没有异步、动态 SQL、没有批处理和看似不可避免的聊天的组合对于大型应用程序来说通常是痛苦的....