Używanie ThreadPool.QueueUserWorkItem w ASP.NET w scenariuszu dużego ruchu

Zawsze miałem wrażenie, że korzystanie z funkcji ThreadPool dla (powiedzmy niekrytycznych) krótkotrwałych zadań w tle uznano za najlepszą praktykę, nawet w ASP.NET, ale potem natknąłem się naTen artykuł co wydaje się sugerować inaczej - argumentem jest, że powinieneś opuścić pulę wątków, aby obsługiwać żądania związane z ASP.NET.

Więc jak dotąd robiłem małe asynchroniczne zadania:

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

Iartykuł sugeruje zamiast tego utworzenie wątku jawnie podobnego do:

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

Pierwsza metoda ma tę zaletę, że jest zarządzana i ograniczona, ale istnieje potencjał (jeśli artykuł jest poprawny), że zadania w tle rywalizują o wątki z programami obsługi żądań ASP.NET. Druga metoda zwalnia pulę wątków, ale kosztem braku ograniczeń i potencjalnego wykorzystania zbyt wielu zasobów.

Więc moje pytanie brzmi: czy porady w artykule są prawidłowe?

Jeśli twoja witryna była tak ruchliwa, że ​​twoja Pula wątków była pełna, to czy lepiej jest wyjść poza pasmo, czy też pełna Pula wątków implikuje, że i tak osiągasz limit swoich zasobów, w którym to przypadku nie powinienem próbować uruchamiać własnych wątków?

Wyjaśnienie: po prostu pytam w zakresie małych, niekrytycznych zadań asynchronicznych (np. Zdalne logowanie), nie drogich elementów pracy, które wymagałyby osobnego procesu (w tych przypadkach zgadzam się, że będziesz potrzebować solidniejszego rozwiązania).

questionAnswers(10)

yourAnswerToTheQuestion