2011-01-11 14 views
1

Wir haben einen Windows Service die eine Reihe von WCF-Diensten hostet und in einem nicht verwandten Teil der App, die extensiven Einsatz der TPLTask Klasse relativ kurze Bits Arbeit asynchron tun macht.Beeinträchtigt die Anzahl der ausgelasteten Worker-Threads im CLR ThreadPool die Leistung von E/A-Threads?

Ich verstehe, dass WCF verwaltete E/A-Threads aus dem ThreadPool verwendet, um Anforderungen auszuführen. Ich habe festgestellt, dass nach der Bereitstellung einer Funktion, die die Verwendung von Tasks Anwendungen deutlich erhöht hat, und als solche auch die Verwendung von ThreadPool-Worker-Threads, die Leistung einiger Webdienste sehr langsam geworden ist. Wir sprechen Minuten statt weniger als eine Sekunde. Die Anzahl von Tasks, die tatsächlich versuchen, zu einer bestimmten Zeit zu laufen, kann zwischen 20 und 1000 liegen, was mich denken lässt, dass jede neue (letzte) Arbeit, die einige CPU-Zeit benötigt, gezwungen werden könnte, einige Zeit zu warten.

Beeinflusst die (in meinem Fall extrem große) Anzahl von aktiven ThreadPool-Worker-Threads die verwalteten I/O-Threads des ThreadPools? Könnten diese beiden in irgendeiner Weise verbunden sein? Oder sollte ich anfangen, woanders zu suchen ...

Danke!

BEARBEITEN: Ich habe gerade eine Stichprobe bei einer Live-Bereitstellung der App beim Versuch, einen der lang laufenden Web-Dienste aufrufen, was ziemlich typisch ist: 70 Tasks ausgeführt, Windows Service-Prozess hat etwa 150 Threads, durchschnittlich CPU-Auslastung 30-60%. Mit Typisch meine ich, dass die CPU-Auslastung im Allgemeinen bei 40% liegt und selten über 80% liegt. Es gibt jedoch eine große Anzahl von Tasks, die ausgeführt werden, und Threads, die vom Prozess verwendet werden.

+0

Haben Sie die gesamte IO/CPU-Aktivität profiliert, um zu sehen, ob Sie die Box einfach angeschlossen haben? –

+0

Ich frage mich auch, ob es hier einige komplexe Probleme mit Blockierung gibt, aber das ist sehr schwer isoliert zu untersuchen. –

+0

Das ist eine Menge von Threads, d. H. 150. Wenn sie "beschäftigt" -Threads sind und alle für einige Zeit auf einem Core streiten, wird viel Zeit verschwendet, nur um zu schlagen, um eingeplant zu werden. Was machen diese Threads? Versuchen Sie, maximale Threads für TPL-Loops zu begrenzen. –

Antwort

1

Hinweis: Ich habe noch nie meine eigene Frage beantwortet, also hoffe ich, dass dies angemessen ist. Fühlen Sie sich frei zu kommentieren oder nicht zustimmen, aber es sieht so aus, als würde dies nicht von jemand anderem beantwortet werden.

Also war das Problem, das unsere Leistungsprobleme verursachte, etwas völlig Unabhängiges und ist jetzt gelöst.

Nachdem dies behoben wurde, reagierten die Web-Dienste erneut zeitnah. Dies führt mich zu der Schlussfolgerung, dass eine ganze Reihe von TPL-Tasks gleichzeitig ausgeführt werden kann (wie die Hunderten in meinem Beispiel), und WCF trotz der starken Verwendung von Thread-Pool-Worker-Threads weiterhin das verwaltete I des Thread-Pools verwenden kann/O-Threads, um Ihre Web-Service-Anfragen effizient zu bearbeiten.

1

Wenn Ihre Aufgaben eine gewisse Zeit für das Schlafen oder Warten auf E/A benötigen, können Sie Ihre Aufgaben mit TaskCreationOptions.LongRunning starten. Dies bewirkt, dass der Thread-Pool mehr Threads erstellt, anstatt darauf zu warten, dass wartende Threads abgeschlossen werden.

task = Task.Factory.StartNew(() => 
    { 
     DoLongRunningWork(); 
    }, TaskCreationOptions.LongRunning); 

Wenn Sie das Konzept testen wollen, gibt es ein Experiment here, die Sie nützlich finden könnten.

Verwandte Themen