Ich hatte immer den Eindruck, dass die Verwendung von ThreadPool für (sagen wir unkritische) kurzlebige Hintergrundaufgaben als bewährte Methode angesehen wurde, auch in ASP.NET, aber dann bin ich auf sie gestoßenDieser Beitrag das scheint etwas anderes zu suggerieren - das Argument ist, dass Sie den ThreadPool verlassen sollten, um ASP.NET-bezogene Anforderungen zu bearbeiten.

So habe ich bisher kleine asynchrone Aufgaben ausgeführt:

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

Undder Artikel schlägt stattdessen vor, einen Thread explizit zu erstellen, ähnlich wie:

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

Die erste Methode hat den Vorteil, dass sie verwaltet und begrenzt wird, aber es besteht die Möglichkeit (wenn der Artikel korrekt ist), dass die Hintergrundaufgaben mit ASP.NET-Anforderungshandlern um Threads konkurrieren. Die zweite Methode setzt den ThreadPool frei, allerdings auf Kosten der Unbegrenztheit und des potenziellen Ressourcenverbrauchs.

Meine Frage ist also, ist der Rat in dem Artikel korrekt?

Wenn Ihre Site so viel Verkehr hatte, dass Ihr ThreadPool voll wurde, ist es besser, Out-of-Band zu gehen, oder würde ein vollständiger ThreadPool bedeuten, dass Sie ohnehin an die Grenze Ihrer Ressourcen gelangen, in diesem Fall Sie sollten Sie nicht versuchen, Ihre eigenen Threads zu starten?

Klarstellung: Ich frage nur im Rahmen kleiner, nicht kritischer asynchroner Aufgaben (z. B. Remote-Protokollierung) nach nicht teuren Arbeitselementen, die einen separaten Prozess erfordern würden (in diesen Fällen werden Sie meiner Meinung nach eine robustere Lösung benötigen).