をサポートする必要性私たちは、レコードの10,000秒を持つアプリケーションでのダッシュボードのいくつかを持って、もちろん私たちは、ページネーションを持っている - しかし、EFは、パフォーマンスの面で非常に貧弱であり、すべてのものを入手します一括検索のクエリは非常に遅いです。は、パフォーマンスを得るためにORMとEntityFrameworkクエリを交換 - のIQueryable
これらのクエリをDapperやORMLiteのMicro-ORMに置き換えるオプションはほとんど見つかっていませんでしたが残念ながら、私たちはダッシュボード/グリッドに必要なiqueryableをサポートしていません以下のように、フィルタリング・検索・ソートなど
私は提唱したい質問は、似たような状況に遭遇したことのある人はありますか？どのようなパスを選んだのですか？
まず、あなたはEFクエリ（AsNoTracking()）で追跡し、これはあなたの最初のブーストを与える必要があります無効にしてください。
次に、データベースのチューニング、REINDEX、より高速なマシンに移動するなど
物事はまだ遅すぎる場合には、マテリアライズに高速である、古き良きLinq2SQLをしようと検討してください。
まだ満たされていない場合は、IQueryableを忘れて、パラメータ化されたビュー/ストアドプロシージャを使用し、Dapperを使用して必要なすべてのパラメータでサーバーを呼び出します。
はい、私が試みた最初のことは、ダッシュボードクエリでAsNoTracking（）を適用することでした。後に - 私たちは、しかし、唯一見るそれらのほとんどされているダッシュボードの場合には、我々は追跡を必要としない、監査の目的のために変更されたエンティティを追跡するためにEFコンテキスト変更（changeTracker）を使用してシステムの他の部分には、追跡している必要がありますすべての努力、結論は、我々は重い検索操作のためのEFを取り除く必要がある – vran
さてあなたは、Dapperのを排除することができます - それは 'のIQueryableを' suppotしません。あなたはLLBLGenPoのようなツールを見ましたか？ EFの最新バージョンを試してみましたか？ –
はい、私たちはEF 6.0+を使用しています - 私はLLBLGenPoを見ていませんでした。 – vran
遅いLINQクエリの例を教えてください。たいていの場合、EFを別のツールに置き換えても、IQueryableサポートが必要な場合は、何も改善されません。 1万レコードしかないダッシュボードは何もありません。何百万ものものでさえそうではありません。クエリキャッシュのようなパフォーマンスを改善するためのオプションやサードパーティのライブラリの多くは、etc..Iは別のORMをサポートすることに切り替えることを考えて前に最初のステップは、「のIQueryable」必ずEFを行うことができない作ることになると思うのフィルタリングを含め、最適化されたインクルードがあります仕事の権利。 –