Siempre he tenido la impresión de que el uso de ThreadPool para tareas en segundo plano de corta duración (digamos no críticas) se consideraba la mejor práctica, incluso en ASP.NET, pero luego me encontré conEste artículo eso parece sugerir lo contrario: el argumento es que debe dejar ThreadPool para tratar con las solicitudes relacionadas con ASP.NET.

Así que aquí es cómo he estado haciendo pequeñas tareas asíncronas hasta ahora:

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

Yel artículo está sugiriendo en cambio crear un hilo explícitamente, similar a:

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

El primer método tiene la ventaja de ser administrado y limitado, pero existe la posibilidad (si el artículo es correcto) de que las tareas en segundo plano estén compitiendo por subprocesos con los manejadores de solicitudes ASP.NET. El segundo método libera el ThreadPool, pero a costa de ser ilimitado y, por lo tanto, potencialmente utilizar demasiados recursos.

Así que mi pregunta es, ¿es correcto el consejo en el artículo?

Si su sitio estaba recibiendo tanto tráfico que su ThreadPool se estaba llenando, entonces, ¿es mejor salir fuera de banda, o un ThreadPool completo implicaría que está llegando al límite de sus recursos de todos modos, en cuyo caso ¿No deberías estar intentando iniciar tus propios hilos?

Aclaración: solo estoy preguntando en el ámbito de las pequeñas tareas asíncronas no críticas (por ejemplo, el registro remoto), los elementos de trabajo no costosos que requerirían un proceso separado (en estos casos, estoy de acuerdo en que necesitará una solución más sólida).