Eu sempre tive a impressão de que usar o ThreadPool para (digamos, não críticas) tarefas de fundo de curta duração era considerado a melhor prática, mesmo no ASP.NET, mas depois me deparei comEste artigo que parece sugerir o contrário - o argumento é que você deve deixar o ThreadPool para lidar com solicitações relacionadas ao ASP.NET.

Então, aqui está como eu tenho feito pequenas tarefas assíncronas até agora:

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

Eo artigo está sugerindo, em vez disso, criar um encadeamento explicitamente, semelhante a:

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

O primeiro método tem a vantagem de ser gerenciado e limitado, mas existe o potencial (se o artigo estiver correto) de que as tarefas em segundo plano estejam competindo por threads com os manipuladores de solicitação do ASP.NET. O segundo método libera o ThreadPool, mas ao custo de ser ilimitado e, portanto, potencialmente usando muitos recursos.

Então, minha pergunta é: o conselho do artigo está correto?

Se o seu site estava recebendo tanto tráfego que o seu ThreadPool estava ficando cheio, então é melhor sair da banda, ou um ThreadPool completo significa que você está chegando ao limite de seus recursos de qualquer maneira, nesse caso você não deveria estar tentando iniciar seus próprios tópicos?

Esclarecimento: Estou apenas perguntando no escopo de pequenas tarefas não críticas assíncronas (por exemplo, registro remoto), itens de trabalho não caros que exigiriam um processo separado (nesses casos, concordo que você precisará de uma solução mais robusta).