IISに展開されているASP.NET(非MVC)サイトがあります。プリコンパイルオプションを設定しました(デプロイ/公開用)。設定は下の画像です。以下の設定のバリエーションを表面から試しましたが、これを行っても大きな改善は見られません。テストするために、プリコンパイルされたサイトとプリコンパイルされていないサイトを2つの異なるIISサイトに展開しています。各サイトのアプリプールにアクセスしてリサイクルします(またはIISリセット)...その後、両方のサイトに個別にアクセスし、最初のページの読み込みをレンダリングするのに同じくらいの時間がかかります(つまり、アプリプール?)、その後、他のaspxページへの呼び出しには、ほぼ同じ時間がかかります(プリコンパイル済みと非プリコンパイル済みの場合)。私は何かが足りないのですか?プリコンパイルは巨大なサイトでのみうまく機能しますか? API呼び出し、DB呼び出しなどがある中規模のサイトをマイニングします。
アプリプールのリサイクル後のサイトへの最初のヒットの読み込み時間を改善するために必要な特定の設定はありますか?または、一般的に、まだコンパイルされていないaspxまたはascxへの最初のヒット応答時間を改善しますか?
「プリコンパイル済み」と「未プリコンパイル済み」の違いは、「未プリコンパイル済み」のサイトページは、.netコンパイラ(csc.exe/vbc.exe)によるこれらの各ページへの最初の要求時に動的にコンパイルされることです。 、タスクマネージャの[プロセス]タブで実際にポップアップを確認できます)。したがって、通常は無視できますが、各ページはコンパイル時間の1回のヒットを取ります。ウェブサイトの/ app_codeディレクトリにもコードファイルがある場合、それらはウェブサイトが起動する前にもコンパイルされるため、最初の起動は「プリコンパイル済み」バージョンよりも少し遅くなります。つまり、web.configの「プリコンパイルされていない」サイトのコンパイル要素の「batch」属性がfalseに設定されている場合、起動時にすべてのページのコンパイルに時間がかかり、サイズによっては時間がかかりすぎる可能性があります。地点。 コンパイル要素(ASP.NET設定スキーマ)
/ app_codeファイルと、たとえばdefault.aspxが「プリコンパイルされていない」サイトでコンパイルされた後は、2つの間で実際のパフォーマンスに違いはありません。
IISのリセットまたはアプリプールのリサイクルでも違いは見られません。一方を展開して両方を実行した後、両方のサイトがコンパイルされるためです。 IISリセット/アプリプールのリセットでは、「プリコンパイルされていない」サイトの再コンパイルは発生しません。ファイルの変更/再デプロイのみが発生します。
見てください ASP.NET動的コンパイルについて 、2つを比較するためにそれが何をするかを理解することが重要です。