1

IIS MMC を介して Web アプリのアプリケーション プールをリサイクルすると、Web アプリ内のページを最初に要求したユーザーは、サイトからの応答が非常に遅くなります。その最初のリクエストの後、その後のすべてのページは問題ありません。ユーザーはサイトからログオフし、後で戻ってくることもでき、速度は速い. 私の懸念は、サイトの最初の初期ロードにあります。午前 3 時にアプリケーション プールを再起動するスクリプトを作成する場合、他に何ができるでしょうか。

a.) サイトにアクセスするユーザーになりすまして、最初の遅い読み込みを発生させることで、ユーザーが朝にアプリを「準備」できるようにします。

また

b.）ユーザーがこのプロセスを開始しなくても、アプリプールにメモリなどをスプールするように指示します。

4

4 に答える 4

1

まず、午前 3 時にアプリをリサイクルするためのスクリプトは必要ありません。アプリ プールには、リサイクル時に選択する設定があります。デフォルトでは、29 時間ごとにリサイクルされると思いますが、これは奇妙な設定であり、変更することをお勧めします。そうしないと、1 日のランダムな時間帯に、セッションが失われたと主張する電話がかかってきます。

問題のアプリ プールに ASP.NET アプリケーションがあると仮定する必要があります。最初の要求時の遅延は、ほとんどの場合、ASP.NET ワーカー プロセスが Web サイトをコンパイルしたり、実行時に必要な DLL をロードしたりする必要があるためです。この問題を解決するために、ほとんどの場合、サイトが完全に読み込まれるようにサイトに定期的なリクエストを送信できるキープアライブ タスクを使用します。Matt の提案も良いものですが、アプリ プールを自分でリサイクルしている場合にのみ問題を解決できます。アプリ プールは、その他のさまざまな理由で独自にリサイクルできます。また、キープアライブにより、ほとんどの場合、負荷を維持できます。

于 2010-04-19T16:42:53.290 に答える
0

これは古い質問ですが、これについて最近の経験があり、投稿したいと思いました。状況に応じて、できることがいくつかあります。

遅い理由は、IIS ワーカー プロセスが一定時間後にスリープ状態になるためです。この設定はIdle Timeoutと呼ばれ、この機能を無効にする場合は 0 に設定できます。しかし、そのような変更を行う前に、これを調査します。

また、IIS が起動すると、DLL がビンに登録されます。小規模なサイトの場合、(標準の .NET DLL 以外の) DLL はおそらくそれほど多くありません。DLLが多数 (未使用の可能性もあります) ある場合は、それらを処理する必要があります。古い DLL/Codeを削除すると、IIS はそれらの処理に時間を浪費することがなくなり、再起動が速くなります。

DotNetNuke サイトには、使用されなくなった約 35 の「レガシー」モジュールがありましたが、まだ /bin フォルダーにありました。/bin 内のモジュールと DLL を削除したことで、Web サイトのリサイクル時間が半分に短縮されました。

もう一つ。サイトがシャットダウンしないように、定期的に読み込まれるKeep Aliveページを構成できます。私たちのホスティング プロバイダーがこのサービスを提供していることは知っています。サイトがメモリに読み込まれたままであることを確認するために、サイトに 30 分ごとにアクセスする簡単な ASPX ページがあります。

于 2015-04-23T01:49:44.397 に答える
0

サイトの最初のロード時にすべてが発生します。できる唯一のことは、リサイクル後の Web サイトへの要求をシミュレートすることです。これは、簡単なアプリケーションで実行できます。.NET でこれを行う最も簡単な方法は、HttpWebRequestクラスを使用することです。

于 2009-07-16T15:33:56.360 に答える
0

同様の問題が発生していました。最初の読み込み時に、JIT コンパイラは MSIL をマシン コードに変換する必要があります。通常、これは非常に迅速に行われ、アプリケーションの使用が初めてでない場合は、"Temporary ASP.NET Files" フォルダーのシャドウ コピーから行われます。アプリケーション アセンブリは、アプリケーションの最初のロード時にここにコピーされるため、「使用中」タイプのエラーを発生させることなく、アプリケーション dll を実際の場所でホット スワップできます。

余談ですが、JIT コンパイラは必要に応じてアセンブリをコンパイルしますが、これは通常は非常に高速です。これは、署名済みアセンブリを使用し、JIT コンパイルを実行するユーザー (つまり、アプリケーション プール ユーザー) がインターネットにアクセスできない場合に変わります。その場合、到達できないインターネット上の署名を検証しようとする間、約 10 ～ 20 秒間そこに留まります。

この問題が発生したとき、エンタープライズ ライブラリ アセンブリを使用していたため、アプリケーション プールのリサイクル後に JIT コンパイル時間が数秒かかっていたのではなく、署名検証のインターネット リクエストでタイムアウトになるまで待機していたため、場合によっては 1 分以上かかっていました。

そのため、JIT (構成設定) 中にアセンブリの署名検証をオフにするか、アプリ プール ユーザーにインターネット アクセスを許可します。

于 2013-02-25T23:54:04.023 に答える