ThreadPools vs Własne wątki dla długotrwałych procesów

Question

Mamy kilka długich procesów biznesowych, które są inicjowane za pośrednictwem usług WCF działających w IIS (tryb zintegrowany) na WS 2008 R2. Te procesy biznesowe zazwyczaj wymagają dużej interakcji z naszym zapleczem SQL Server. Stworzyliśmy niestandardową implementację kolejki zadań, w której żądania są kolejkowane za pośrednictwem początkowego wywołania usługi, a następnie wykonywane w oparciu o priorytet. Wykonanie tego może zająć dużo czasu (ekstremalne 20-30 minut). Klienci mogą następnie wysyłać zapytania do serwera o postęp własnych zadań w tle.

W naszej obecnej realizacji zadania odpalają się na osobnym wątku, aby wykonać, a nie z ThreadPool. Zrobiono to, ponieważ reading recommendations nie uruchamiał długotrwałych zadań wykorzystujących ThreadPool, aby uniemożliwić odgórne wyświetlanie żądań ASP.NET. Kontrolujemy liczbę wątków tworzonych przez umieszczenie górnego limitu liczby zadań tła, które mogą być wykonywane jednocześnie. W ten sposób staramy się kontrolować obciążenie procesora i zapobiegać zbyt dużemu przełączaniu kontekstu wątków. Podczas gdy to wszystko się dzieje, oczywiście nadal musimy obsługiwać zwykłe "on-line" żądania aplikacji.

Po przeczytaniu this post przez Thomasa Marquardta martwię się o to, że nie używamy ThreadPool, ponieważ nie będziemy korzystać z heurystyki tuningowej. Rozwiązujemy już problem zamykania, o którym Thomas wspomniał, zahaczając o zdarzenie ApplicationEnd i anulując długo działające zadania. Moje pytanie brzmi: czy powinniśmy przejść do używania ThreadPool? A co z tymi wątkami związanymi na długie okresy czasu? Jeśli dobrze rozumiem Thomasa, mówi on, że to nie ma znaczenia, ponieważ ThreadPool dostroi się, by stworzyć więcej żądań służących normalnym operacjom on-line? Przeczytałem również this StackOverflow question, który obejmuje te same podstawy, ale nadal nie jestem pewien co do dalszego rozwoju.

Answer 1

To nie jest dokładnie to, o co prosiłeś - ale dlaczego nie wykonywać długo działających zadań w oddzielnym procesie (powiedzmy, że usługa Windows) razem - tak czy inaczej budujesz kolejkę priorytetową, a klienci będą zwracać się z zapytaniem o wyniki czas później. Byłoby to możliwe z takim podejściem, w którym usługi WCF Services skierowane z przodu ustawiają kolejki żądań i odpowiadają na zapytania o aktualizację statusu, podczas gdy usługa działająca w tle nadal wyświetla żądania. Umożliwiłoby to nawet przetwarzanie procesów roboczych itp. Bez obaw o zakończenie aktualnie wykonywanych zadań. Jedyny problem, który widzę, jest związany z komunikacją procesową, ale powinien być nieistotny w porównaniu do czasu, jaki zajmuje zadanie (ponieważ są one długo uruchomione).

Answer 2

Moja sugestia to unikanie ThreadPool, ponieważ mam dokładnie problemy z głodem wątku sugerowane w podanych linkach.

Nasz produkt umożliwia użytkownikowi wywołanie połączenia z serwisem internetowym wykonującym serię ofert. Może to być długotrwały proces trwający do 40 minut, proces wyceny jest intensywny, więc używamy puli wątków na naszym czterordzeniowym serwerze, aby uzyskać maksymalne wykorzystanie procesora.

Jednak, ponieważ ASP.NET wygląda na to, że używa puli wątków do obsługi żądań, mamy problem z tym, że wszelkie nowe zadania przesłane przez użytkowników nigdy się nie kończą, dopóki pierwsza praca nie zostanie zakończona z powodu braku dostępnych wątków w basen. Aby obejść ten problem, używam klasy, którą niedawno znalazłem w Internecie pod nazwą ThreadPoolThrottle. Doprowadziło to trochę do problemów, ale wraz z rosnącym wykorzystaniem systemu napotykamy na te same problemy.

Zastanawiam się teraz nad sugestią VinayC o uruchomieniu cytatów z procesu, aby zapobiec głodowaniu wątków w mojej aplikacji asp.net.