數據訪問的性能和可伸縮性

我已經看了很多答案，但還沒有找到滿意的答案。這是問題所在。我需要創建一個Web應用程序。技術將基於微軟的堆棧（ASP.NET 4，C＃，SQL Server 2008）。基礎設施將託管在亞馬遜EC2上。我需要決定如何訪問數據。數據訪問的性能和可伸縮性

實體框架
平面老ADO.NET

在峯值可以有大約10萬人在同一時間訪問本網站。爲了達到這樣的規模並且有一個不錯的表現，Entity Framework可以被使用，還是更好地回退到ADO.NET？ Entity框架與ADO.NET有性能問題嗎？

任何提示將有所幫助。

來源

2012-01-01 Rohit Harshvardhan

由於您正在構建高流量的網站，您可能應該使用簡單的Ado.net。但是，Micro-ORM可以成爲您的選擇。例如，SO使用單個文件ORM dapper dot net。如果你看錶演表，你會看到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

來源

2012-01-01 09:55:31 adt

謝謝你們。這有很大幫助。我猜實體框架已經出來了。我正在研究短小精悍。在一天結束的時候，ADP.NET就是我可能會遇到的問題。它很傷心，因爲我非常喜歡EF。但我想不能吃蛋糕，也吃不完。 – 2012-01-02 15:30:33

EF採用的最大性能命中之一是生成視圖和準備查詢。看到這裏：http://msdn.microsoft.com/en-us/library/cc853327.aspx也就是說，如果你看看關於這個主題的更新信息，你會發現在.net 4.5上的EF5 +會自動考慮到這一點編譯所有查詢，從而顯着提高性能。請參閱：http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx。但是，您仍然可以通過更新到4.5來獲得EF4的這種提升，或者只是手動編譯查詢。 – Brandon 2013-10-28 13:39:02

實體框架，LINQ2SQL和其他OR映射器在應用程序服務器端的運行時間損失很小。然而，在大多數實際應用中，罰款低於1％。與大多數技術一樣（以不同的方式做同樣的事情），性能影響並不取決於技術，而是取決於你如何實現它們。如果您鍵入一個EF查詢，可以轉換爲幾個循環遍歷數據庫的SQL查詢，那麼您可以通過EF發生災難性故障。但這些情況很容易發現並且易於修復。

來源

2012-01-01 09:50:24

以我的經驗，則判爲EF，LINQ2SQL和其他奧姆斯比1％高得多 - 沒有異步，動態SQL，沒有配料，看似組合不可避免的討厭通常是痛苦的大型應用程序... – RickNZ 2012-01-02 08:05:29

數據訪問的性能和可伸縮性

回答

相關問題