IISアプリケーションプール-停止/開始とリサイクル
本番環境のWebアプリの1つで、アプリプールを手動でリサイクルすると、タスクマネージャーでの監視に基づいて、リサイクルされたワーカープロセスが実際に完全に破棄されるまでに60秒以上かかることがあります。ただし、アプリプールを完全に停止すると、ワーカープロセスはほぼ瞬時に（1〜2秒以内に）終了します。
だから、私の質問は2つあります：
a）アプリプールが停止するのではなくリサイクルされるときに、プロセスを破棄する（そして、より重要なことには、使用/ロックされているリソースを解放する）のに長い時間がかかるのはなぜですか。そして
b）トラフィックのサーバーへの転送を停止したと仮定すると、リサイクルの代わりに停止/開始しない理由はありますか？
編集：
明確にするために、アプリプールをリサイクルまたは停止する前に、問題のサーバーへのトラフィックの送信を停止します（サーバーは負荷分散クラスターにあり、サーバーをロードバランサーから削除します）。したがって、理論的には、アプリプールに対して何かをしているときにWebサイトにリクエストが送信されることはありません。
Edit Part Deux：
イガルのリンクを読んだ後、何が起こっているのか私にはかなり明白に思えます。アプリプールをリサイクルすると、新しいプロセスが開始されますが、トラフィックがまったくないため、新しいプロセスが機能していると登録されていないため、タイムアウト（90）になるまで古いプロセスはシャットダウンされません。秒）。
その知識があれば、「リサイクル」機能は特にライブサーバーの途中で使用することを意図していることは明らかであり、事前に手動でトラフィックを排出しているため、代わりに停止/開始を使用する必要があります。
a） 重複リサイクル のため。 「古い」プロセスが新しいプロセスが開始するのを待つ期間があります。
b）いいえ。私の知る限り。
私がリコールを正しくリサイクルすると、既存のすべてのリクエストが終了して、アプリケーションプールがリサイクルされます。停止すると、停止した瞬間に停止します。
このリンク によれば、
Stopping–アプリケーションプールを停止することにより、このアプリケーションプールにサービスを提供するすべてのIISワーカープロセスにシャットダウンを指示します。そして、アプリケーションプールが再び開始されるまで、追加のワーカープロセスが開始されないようにします。これにより、ワーカープロセスの正常なシャットダウンが開始され、各ワーカープロセスはすべての要求を排出して終了します。 。
各アプリケーションプールの定義のprocessModel要素のshutdownTimeLimit構成プロパティで指定された時間内にワーカープロセスが終了しない場合（デフォルト：90秒）、WASは強制終了します（ネイティブデバッガーが接続されている場合、これは発生しません）。 。
したがって、アプリケーションプールの停止は、ASP.NETアプリケーションドメインのアンロード、FastCGI子プロセス、およびプロセス内のアプリケーション状態の損失を引き起こす破壊的なアクションです。
Recycling–アプリケーションプールをリサイクルすると、そのアプリケーションプールで現在実行中のすべてのIISワーカープロセスが正常にシャットダウンされますが、プールの停止とは異なり、新しいIISワーカープロセスをオンデマンドで開始して、後続の要求を処理できます。
アプリケーションプールのリサイクルは、操作を中断することなく、IIS自動的に更新されないワーカープロセス（ほとんどはグローバルレジストリキー））によってキャッシュされたアプリケーションの状態と構成をリセットする良い方法です。これにより、ほとんどの場合、アプリケーションプールのリサイクルがIISRESETの優れた代替手段になります。