В ходе разработки веб-приложения с асинхронной подгрузкой данных в кэш встал вопрос, а влияет ли использование потоков из ThreadPool (напрямую или через Timer) на выделение потоков для обработки запросов внешних пользователей. После экспериментировния с параметрами конфига

<httpRuntime minFreeThreads="1" minLocalRequestFreeThreads="1"/>
<processModel autoConfig="false" maxWorkerThreads="3" minWorkerThreads="1" />

и написания парочки страниц, одна из которой занимает надолого поток

protected void Page_Load(object sender, EventArgs e)
{
   Thread.CurrentThread.Suspend();
}

а вторая в том же приложении в Page_Load отоброажает кол-во потоков в пуле:

protected void Page_Load(object sender, EventArgs e)
{
int workTr, compTr;

  System.Threading.ThreadPool.GetAvailableThreads(out workTr, out compTr);

  Response.Write("<br> Available1 " + workTr);
  Response.Write("<br> Available2 " + compTr);

}

а также изменением значений параметров maxWorkerThreads и просмотром количества потоков выделяемых в пуле пришел к следующим выводам:

ASP.NET использует общий с доменом приложения пул потоков. Однако, макс. количество потоков предоставляемое web-приложению для одновременной обработки запросов определяется атрибутами элементов httpRuntime и processModel.
Но это число ограничено размером пула, если значение атрибута maxWorkerThreads превысит разрешенное кол-во потоков пуле.

Кроме того, выделение потока из пула под внутренние нужды логики приложения может затормозить отработку
запроса внешнего пользователя, т.к. выделение новых потоков происходит с задержкой в 500 мс на каждый
новый поток, если в пуле нет свободных потоков.

Если все это так, то запуск нескольких параллельных потоков по таймеру наверное не должен сильно отразится на времени отклика для пользователей. Вот только не могу понять — какой параметр в вышеуказанных секциях указывает за минимальное кол-во потоков в пуле, отведенных под нужды ASP.NET, дабы обеспечить быстрое время отклика.