回答:
これは、シミュレーション（またはソースコードへのアクセス...> sigh <）が、ある程度の信頼度で動作を確認する唯一の方法となるケースの1つに似ています。
CPUクォータリサイクルのイベントログエントリのドキュメントでは、リサイクルについて次のように説明しています。
既定では、アプリケーションプールのリサイクルは重複しています。つまり、シャットダウンされるワーカープロセスは、新しいワーカープロセスが開始されるまで実行され続けます。新しいワーカープロセスが開始すると、新しいリクエストがそれに渡されます。古いワーカープロセスは、既存の要求の処理が終了した後、または構成されたタイムアウト後のいずれか早い方でシャットダウンします。このリサイクル方法により、クライアントへのサービスが中断されません。ただし、アプリケーションプール内のアプリケーションが同時に複数のインスタンスを実行できない場合は、オーバーラップローテーションを無効にできます。
当然のことながら、過度のCPU消費のためにワーカープロセスを終了すると、保留中のリクエストは完了できません（CPUクォータを使い果たしているため）。
主な懸念事項についてお話しします。新しいワーカープロセスが自動的に起動されないだろうと私を信じさせるようなことは何も見ていません。Stack Overflowリンクのステートメントでは、IISで使用されるアルゴリズムが実際にリサイクルをCPUクォータの枯渇を測定するために使用されるタイマーの解決に結び付ける可能性があるかどうか疑問に思っています。CPUを浪費するサーバー側コンポーネントを作成してテスト環境に展開し、そのリサイクル動作がどのように機能するかを確認することは、私が知る最良の方法です。数秒間タイトなループに留まり、既知の文字列を返し、並列の「wget」プロセスのプールのようなものでテストハーネスを実行しているクライアントと組み合わせる単純なコンポーネントで十分です。