累積SQL查詢執行時間* MUCH *比EF ExecuteStoreCommands低

Question

因此，我一直在對此MVC應用程序進行性能分析，並且注意到某些查詢速度很慢，因此自然而然地我對應用程序和數據庫進行了概要分析。

這些是發現：

根據MSSQL事件探查器，對於29條SQL命令，所有DB調用的總和為48ms 。 這似乎是合理的。

編輯：這29個調用中的每一個都帶有exec sp_reset_connection命令（不確定是否相關）。

這是奇怪的部分，應用程序分析說：

實體框架的

internal virtual DbDataReader ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)

花了578毫秒執行。 或者讓我進一步分解它。

 private ObjectResult<T> GetResults(MergeOption? forMergeOption)
{
  this.QueryState.ObjectContext.AsyncMonitor.EnsureNotEntered();
  IDbExecutionStrategy executionStrategy = DbProviderServices.GetExecutionStrategy(this.QueryState.ObjectContext.Connection, this.QueryState.ObjectContext.MetadataWorkspace);
  if (executionStrategy.RetriesOnFailure && this.QueryState.EffectiveStreamingBehaviour)
    throw new InvalidOperationException(Strings.ExecutionStrategy_StreamingNotSupported((object) executionStrategy.GetType().Name));
  else
    return executionStrategy.Execute<ObjectResult<T>>((Func<ObjectResult<T>>) (() => this.QueryState.ObjectContext.ExecuteInTransaction<ObjectResult<T>>((Func<ObjectResult<T>>) (() => this.QueryState.GetExecutionPlan(forMergeOption).Execute<T>(this.QueryState.ObjectContext, this.QueryState.Parameters)), executionStrategy, false, !this.QueryState.EffectiveStreamingBehaviour)));
}

從578毫秒中耗時552毫秒。

如果我進一步分解它。

public ObjectResult<T> Execute(MergeOption mergeOption)
    {
      EntityUtil.CheckArgumentMergeOption(mergeOption);
      return this.GetResults(new MergeOption?(mergeOption));
    }

397ms

GetEnumerator花費155ms ，該方法調用Lazy方法“ CreateValue”等。

我會在這里停止。

這些執行時間由Jetbrains DotTrace測量。

我確實意識到擁有EF本質上意味着“一些”開銷。 但這似乎是過分的。

EF 6.1.2，SQL Server 2012標准版

我問得太多了嗎？ 當我期望“一些”開銷而不是12倍開銷時，我是否不合理？

還是我只是沒有采用正確的方法？

最好的問候，T.

Answer 1

默認情況下，Entity Framework不僅執行查詢，而且還對數據進行序列化和反序列化，它的作用遠不止於此。第一次運行任何EF命令時，它花費的時間比后續調用要多得多，因此在測量調用時間之前先進行蠕蟲向上調用。

EF所做的某些驗證正在數據庫上再次進行，例如數據完整性。

context.Configuration.AutoDetectChangesEnabled = false;

這將大大減少EF調用時間，但也會減少功能。

嘗試進行更多挖掘，因為根據情況的不同，更改默認配置值可能會大大改變每次調用的時間。

最后，是的，EF是性能上的佼佼者，但在開發熱潮期間消除了許多問題，服務器便宜而且程序員昂貴。

Answer 2

也許我有點遲了，但是請記住，探查器也有它自己的開銷，它取決於配置文件類型。 對於“采樣”來說，它很小，而對於“時間軸”來說，它稍大一些，然后進行“跟蹤”，而最繁重的是逐行。 因此，要獲得最准確的絕對函數執行時間，應使用采樣。

但是，在dotTrace 6.1中，可以選擇在時間軸模式下分析客戶端SQL交互，包括連接打開時間，執行和結果傳輸開銷。 因此，您可以嘗試找出問題所在。