Это похоже на один из тех случаев, когда симуляция (или доступ к исходному коду ...> sigh <), вероятно, будет единственным способом увидеть поведение с какой-либо степенью достоверности.
Документация для записи в журнале событий для утилизации квот процессора говорит об утилизации следующим образом:
По умолчанию повторное использование пула приложений перекрывается, что означает, что рабочий процесс, который должен быть остановлен, продолжает работать до тех пор, пока не будет запущен новый рабочий процесс. После запуска нового рабочего процесса ему передаются новые запросы. Старый рабочий процесс завершает работу после того, как завершает обработку существующих запросов или по истечении установленного времени ожидания, в зависимости от того, что наступит раньше. Этот способ утилизации обеспечивает бесперебойное обслуживание клиентов. Однако если приложение в пуле приложений не может запускать более одного экземпляра одновременно, перекрывающееся вращение может быть отключено.
Мне кажется, что по определению завершение рабочего процесса из-за чрезмерного потребления ЦП будет означать, что отложенные запросы не будут разрешены для выполнения (так как они исчерпывают квоту ЦП).
Если говорить о вашей главной заботе: я не вижу ничего, что могло бы заставить меня поверить, что новый рабочий процесс не будет запущен автоматически. Утверждение в вашей ссылке переполнения стека заставляет меня задаться вопросом, может ли алгоритм, используемый IIS, на самом деле связывать рециркуляцию с разрешением таймера, используемого для измерения исчерпания квоты ЦП. Лучший способ, который я знаю, чтобы определить это, - написать бесполезный серверный компонент на ЦП, развернуть его в тестовой среде и посмотреть, как действует его переработка. Простого компонента, который сидит в узком цикле в течение нескольких секунд, а затем возвращает известную строку, в сочетании с клиентом, выполняющим тестовую программу с чем-то вроде пула параллельных процессов "wget", может быть достаточно.