Hallo Ingo,
Threading hilft nur bei CPU-bezogenen Problemen, d.h. während der eine Thread von einem bestimmten Prozessorkern abgearbeitet wird, kann parallel dazu ein anderer Thread in einem weiteren Kern abgearbeitet werden. Das steigert die Effizienz solange die Anzahl
der gleichzeitig ausgeführten Threads in einem gesunden Verhältnis zur Anzahl der Prozessorkerne ist (Pi mal Daumen: 2 x Anzahl der Kerne) und die Threads in der zugeteilten Zeitspanne was tun und nicht warten.
Das Downloaden der Daten ist aber keine CPU-bezogene Operation, sondern eine E/A-Operation. Diese Art von Operationen zeichnen sich dadurch aus, dass sie die meiste Zeit über auf das Abschließen der E/A warten.
Egal wie Du diese Arbeit auf die Prozessorkerne verteilst, wird dies das Herunterladen der Daten nicht beschleunigen. Im Gegenteil: Wenn Du zuviele Threads erzeugst, unterbricht der Windows Scheduler die einzelnen Threads häufiger und das kostet Zeit und
Performanz. Auf der anderen Seite bombardierst Du den Server ununterbrochen mit Anfragen, was die Sache auch nicht einfacher macht.
Wenn Du - aus mir unbekannten, hier nicht angeführten Gründen - Threading benutzen mußt, dann verwende doch den Threadpool. Optimal funktioniert das, wenn das Herunterladen der Daten < 250 ms ist.
Bei E/A-Operationen sollte man asynchron arbeiten (nicht zu verwechseln mit Threading). In C# 5.0 gibt es dazu async/await. Wenn Du etwas wie WebClient.DownloadStringAsync() verwendest, dann kannst Du über ThreadPool.QueueUserWorkItem(DoDownload) arbeiten.
Das ist zwar weniger optimal als async/await, funktioniert aber recht gut, weil die Verwaltung des ThreadPools von der CLR übernommen wird. Über die Methode
ThreadPool.SetMaxThreads() kannst Du beeinflussen wieviel Threads maximal gleichzeitig aktiv sein dürfen. Die restlichen Threads kommen in eine Warteschlange, Du mußt schon aufpassen, dass die nicht zu groß wird, denn sonst nimmt die CLR an, dass die CPU
zu beschäftigt ist und die Scheduling-Performanz der Threads im Pool wird suboptimal.
Gruß
Marcel
