ストアドプロシージャとエンティティフレームワークのパフォーマンス

Question

エンティティモデルを使用してストアドプロシージャを呼び出すと、それを直接呼び出しよりもパフォーマンスが低下するという明らかな理由はありますか？

最初に、私はSPが正確にで動作するとは思っていません。そして、SPに直接アクセスするときにEFがしなければならない様々なことがあります。

これ以外にも、3列の文字列を返すクエリがあります。私がEnterprise Managerを介して実行すると、すぐに実行されます。私がEF経由で走らせると、約6秒かかります。確かに、この結果は複合型にマップされているが、私はSQL Serverプロファイラによるクエリを実行したら、それは遅延がSQLサーバー上で起こることを確認するためには明らかです：ダイアグラムで

、1 Enterprise ManagerからSQLが呼び出されたことを示します.2は、EFを使用してアプリケーションを介して呼び出されていることを示します。

私はここで間違っていますか？おそらく2〜2秒の遅れが予想されますが、その差はあまりにも大きいようです。

EDIT：

ADO.Net経由で呼び出されたときに、ストアドプロシージャも実行速度が遅いようです。私の同僚は、.Netがキャッシュしている悪い実行計画とは何かだと思っているようです。ストアドプロシージャを編集して再度保存すると、キャッシュにあったものがすべてクリアされたように見え、ストアドプロシージャへのADO.NetとEFの両方の呼び出しがうまく機能します。

これまでに他の誰かがこれに遭遇しましたか？

Answer 1

this thread on SQL Server forumをご覧ください。それは少し似ており、いくつかの手がかりを与えるかもしれません。要するに、SSMSとADO.NETのSQL Server実行環境オプションが異なると、実行計画が異なります。 SQL Serverのプランキャッシュをクリアすると役立ちます。

Answer 2

Pavel GatilovがARITH ABORTの設定で頭に浮かんでいるようだが、私は自分の発見についてもう少し詳しく投稿するつもりだと思った。

This postは、同様の問題を回避するための議論でカバーしています。 EF接続とSQL.Data.Clientの間に "SET ARITHABORT ON"を持つDBへの呼び出しの前にラッパークラスを書くことが可能です。 MSDNのThis articleについて詳しく説明しています。

変更の複雑さを見て、アプリケーションをストアドプロシージャの使用から完全にEFを使用するように移動することを考慮して、弾丸を噛んで、EFデータモデルにSP機能を移行します。

Answer 3

単一のトランザクションで同じ呼び出しではないです

INSERT INTO foo (col1, col2) SELECT col1, col2 (with all 100 rows of the changes) 

ただ、両方のケースで生成されたクエリでかいま見を取り、データベースに直接、そのクエリをテスト100回

EXEC SP_foo_INSERT param1, param2 

を呼び出すより。それの実行計画が何であるかを見てください。