私のコンテキストで〜300 DbSetsがあり、アプリケーションロード（FirstOrDefault（）のインデックス付きフィールド上）の最初のクエリは〜40秒かかります。これを改善するなぜ私のEFコードが最初に生成されたビューは効果がありませんか？
は、私がここでT4テンプレートを使用してEF 4.3.1コードファーストで生成済みのビューを使用しようとしています：
を、私はそれをコンパイルし、私は何のパフォーマンスの違いを見ません。私はそれが、私が経験している苦しいスタートアップを助けると思っていた。
役立つでしょうか？そうでない場合、事前に生成されたビューは正確にはどのようなものですか？そして、何かがありますか？起動時間を改善するにはどうすればよいですか？私の文脈を分割することは、控えめに言えば痛いことです。
実際には、最初に参照されたエンティティがであるアセンブリで、事前生成されたビューを検索するように見えますが、DbContextがあるアセンブリではありません。詳細はこちらhttp://blog.3d-logic.com/2012/06/13/entity-framework-codefirst-view-generation-templates-on-visual-studio-code-gallery/#comment-76を参照してください。
これを回避するために、新しいエンティティを作成してコンテキストのアセンブリに配置し、最初のDbSetとしてリストしました。今それはそれをピックアップし、うまく動作します（これはばかげています）。
この現象は、データベースとモデルファーストでも発生します。私の事前生成されたビューは、同じアセンブリ内のコンテキストでコンパイルされます。それらは、コンソールまたはWindowsサービスアプリケーションで取得されますが、IISでは取得されません。私はT4を使ってそれらを生成し、ログを追加しているので、それを見ることができます。 –
も同じ問題がありますが、私は解決策を理解していません。私は私のPOCOエンティティと私のedmxと別のアセンブリとasseblbyを持っています。私はedmxを持っている私の議会でエンティティをクレメートする必要がありますか？最初のDBContextとしてどのようにリストしましたか？ありがとう。 –
特定のORMのようなNHibernateとEFは、単に起動が遅くなります。この遅さを「修正」するのではなく、アプリケーションプールが起動するたびにIISがこのコードをトリガーするようにして、この問題を解決したい。この問題を解決するには、アプリケーションプールを自動的に開始するようにIISを構成する必要があります。このソリューションは、.NET 4およびIIS7.5以降でのみ使用できます。
あなたはObjectContextをロードIProcessHostPreloadClientを持つクラスを実装し、あなたのweb.configファイルにserviceAutoStartProvidersノードを追加し、アプリケーションのアプリケーションプールのSTARTMODE =「AlwaysRunning」を設定することによって、それを使用するようにアプリケーションを構成します。
詳細については、Scott Gu's blogを参照してください。
これは良い解決策ですが、痛みを伴って私がコントロールできない理由から、私はIIS6/32ビットWindow Server 2003に固執しています。そのため、IProcessHostPreloadClientを使用する方法はなく、サイトはいつもメモリ不足からリサイクルしています... –
定期的にリサイクルしても問題ありません。このアプローチでは、アプリケーションプールが再び起動することを確認しますが、通常の動作では、呼び出しが到着するまで起動しません。 しかし、IIS6はデッドブレイカーになります。 Windowsサービスのセルフホスティングはオプションですか？ – Mithon
これは問題です。ユーザーがサイトを使用していて、リサイクルが開始され、次のリクエストが新しいアプリケーションプールに送られ、それが永久にかかり、サイトがハングアップしているように見えます。 –
ASP.NETには、あらかじめコンパイルされたビューがあります。私も同じ問題がありました。 – jrummell