13

Windows 2008 の IIS7 で ASP.NET 3.5 Web サイトを実行しています。

IIS (iisreset) を再起動してからページにアクセスすると、最初の起動が非常に遅くなります。

Process Explorer に次のアクティビティが表示されます。

  • w3wp.exe が生成されますが、約 60 秒間 0% の CPU アクティビティが表示されます
  • 最後に、w3wp.exe の CPU 使用率が約 5 秒間 50% になり、ページが読み込まれます。

この間、CPU を使用している他のプロセスも見当たりません。基本的にハングするだけです。

その間ずっと何が起こっているのですか?この間ずっとかかっているものを追跡するにはどうすればよいですか?

4

7 に答える 7

6

同様の問題があり、署名証明書の失効をチェックする Windows がタイムアウトすることが判明しました。サーバーがどこか (例: crl.microsoft.com) を呼び出そうとしているかどうかを確認します。プロキシの設定が間違っているのではないでしょうか? または途中でファイアウォール?私たちは最終的に、サーバーを十分に制御でき、「コール ホーム」したくないと判断したため、単純にチェックを無効にしました。.NET 2.0 SP1 以降では、machine.config に次を追加することでこれを行うことができます。

<runtime> <generatePublisherEvidence enabled="false"/> </runtime>

これをapp.config/web.configに入れるだけでよいかどうかわかりません。

于 2009-12-30T23:20:02.373 に答える
4

フロント エンド Web サーバーからデータベース サーバーへの初期接続を確立する際に、ネットワーク遅延が発生していることがわかりました。

この問題は、Windows 2008 および特定のネットワーク ハードウェアに特有のものでした。

解決策は、Web サーバーで以下を無効にすることでした。

于 2010-11-05T16:48:34.500 に答える
4

IL は Just-In-Time コンパイラによってマシン ネイティブ コード (アセンブリ) に変換されており、すべての魔法が起こるまで待つことができます。

ソース コードをマネージ コードにコンパイルするとき、コンパイラはソースを Microsoft Intermediate Language (MSIL) に変換します。これは、効率的にネイティブ コードに変換できる、CPU に依存しない一連の命令です。Microsoft 中間言語 (MSIL) は、多くのコンパイラの出力として使用される翻訳です。これは、ジャストインタイム (JIT) コンパイラへの入力です。共通言語ランタイムには、MSIL をネイティブ コードに変換するための JIT コンパイラが含まれています。

Microsoft Intermediate Language (MSIL) を実行する前に、.NET Framework ジャストインタイム (JIT) コンパイラによってネイティブ コードに変換する必要があります。これは、JIT コンパイラと同じコンピューター アーキテクチャで実行される CPU 固有のコードです。移植可能な実行可能 (PE) ファイル内のすべての MSIL をネイティブ コードに変換するために時間とメモリを使用するのではなく。実行中に必要に応じて MSIL を変換し、結果のネイティブ コードをキャッシュして、後続の呼び出しでアクセスできるようにします。

ソース

于 2009-09-17T22:27:46.993 に答える
4

それは、asp.Net ページを中間言語 + JIT コンパイルにコンパイルすることです。これは、ページが最初に読み込まれたときにのみ発生します。( http://msdn.microsoft.com/en-us/library/ms366723.aspxを参照)

それが本当に気になる場合は、サイトをプリコンパイルすることで発生を防ぐことができます。

編集:質問をもう一度読んでください-60秒は非常に長く、その間にプロセッサのアクティビティが見られると予想されます。System および Application 宛先のエラー/メッセージについては、EventLog を確認してください。また、この 60 秒間に w3wp プロセスのクラッシュ ダンプを作成してみてください。コール スタックのいくつかを見ることで、そのプロセスが何を行っているかを認識できる可能性があります。

毎回正確に60 秒かかる場合は、何かがタイムアウトするのを待っている可能性があります。60 秒は適切なラウンド数です。ドメインコントローラーなどへの適切な接続があることを確認してください...

(より良い仕事をするIIS診断ツールがいくつかある場合、残念ながら私はそれらを認識していません。この質問はServerFaultに適している可能性があります。上記は、トラブルシューティングに対する開発者らしいアプローチです:- p)

于 2009-09-17T22:28:09.553 に答える
2

60 秒を超えると怪しげに聞こえます。test.html ページを実行して、所要時間を確認してください。これにより、IIS7 の役割が分離されます。

次に、web.config、global.asax、およびアプリケーション フォルダーの名前を一時的に変更し、test.aspx ページ (非常に単純なページ) を試します。これにより、ASP.NET が分離されます。

どちらも高速 (約 10 秒) であれば、それはあなたのアプリケーションです。ただし、どちらかが遅い場合は、アプリケーションではなく、サーバー自体に問題があります。

于 2009-09-17T23:48:05.823 に答える
1

これは JIT コンパイルとは関係ありません。通常の C# コンパイラは、コード ビハインド ファイル (.aspx.cs) を中間言語にコンパイルして、このアセンブリが存在しない場合、またはコード ファイルが変更されている場合、起動時にアセンブリに変換します。Web サイト アセンブリは、Web サイトの "bin" フォルダーにあります。

実際にはその後に JIT コンパイルが行われますが、これは非常に高速で、数分もかかりません。JIT コンパイルは .net アプリケーションを起動するたびに行われ、1 ビュー秒以上かかることはありません。

コンパイル済みの Web サイト アセンブリ (YourWebsite.dll) を bin フォルダーに配置すると、Web サイトのコピーを回避できます。また、aspx ファイルのみを展開し、コード ビハインド ファイル (aspx.cs) ファイルを残しておくこともできます。

于 2009-09-17T23:02:47.270 に答える