60000 Dateien mit Threads downloaden

[moritz]

Servus Leute,

ich muss in einem Programm 60000 Dateien ( legal! ) downloaden. Da das mit einem Thread fürchterlich lange dauert, würde ich dafür gerne eine gewisse Anzahlö an Threads starten, die die datei downloaden und dann einen neuen Thread starten.
Die Seiten sind à la seite.com/download.php?id=* durchnummeriert. Allerdings habe ich keine Ahnung, wie ich das realisieren soll oder wieviele Threads ich starten soll ( 2000 Kbit down, 512MB Ram ).
Habt ihr Tutorials, Ansatzpunkte oder Tipps dafür für mich?

Gruß

[Meflin]

wenn dus nur auf diesem systemb brauchst: ich würd einfach ausprobieren ab welcher threadanzahl das multithreading nur blockiert. ich denke so mehr als 500 dürft dein system auch nicht mehr flüssig bearbeiten...

[Nordmende]

Ein Threading Tutorial gibt es hier: www.luckie-online.de. Generell gilt bei Operationen, die hardwareabhängig sind, dass je mehr Threads man startet, es nicht um so schneller geht, da alle Threads auf die gleiche Ressource, die festpaltte, zugreifen müssen. Musst du also ausprobieren und einen Kompromiss finden.

Lösen würde ich das über einen Steuerthread, der die Worker Threads verwaltet. Wie das geht kannst du hier bei diesem Portscanner gucken: http://assarbad.net/de/stuff

[Nordmende]

Zitat:

Zitat von Meflin

ich denke so mehr als 500 dürft dein system auch nicht mehr flüssig bearbeiten...

Der Flaschenhals ist nicht das System, was die Threads verwaltet, sondern die Festpaltte, wie ich schon geschrieben habe.

[Meflin]

auch der prozessor ;-) je schneller der ist desto mehr threads kannst du starten. kommt auch auf die benötigte rechenleistung der threads an!

[Nordmende]

Öhm, also wenn der Prozessor langsamer ist, wie die Festplatte schreiben kann, dann hat er einen C64 Prozessor und eine moderne Festplatte. Der Flaschenhals ist definitiv die Festplatte. Selbst zwei Threads können keinen Sinn machen, wenn jeder von den beiden eine große datei schreiben soll. Die Festpaltte kann immer nur an einer Stelle gleichzeitig schreiben. Desweiteren verwaltet nicht der Prozessor die Threads, sondern das Betriebssystem.

[Meflin]

wer sagt dass er das unbedingt auf der festplatte speichern will? ich denke im ram behalten und am ende speichern reicht voll...

[Brüggendiek]

Hallo!

Der Flaschenhals sind weder Prozessor noch Festplatte!

Das erreichbare Tempo hängt ab von:
1. der Geschwindigkeit der Internet-Anbindung und
2. der Leistungsfähigkeit des Servers.

Unter normalen Internet-Verhältnissen (Telefon oder DSL mit max. 3MBit/s) ist nämlich die Leitung das Problem. Zusatzlich kann es bei schnellen Leitungen auch passieren, daß der Server aufgrund weiterer Anfragen von anderen Stellen (der Anbieter hat nur "ein Stück vom Server" gemietet und teilt sich das Gerät mit belastenden Anwendungen) langsamer als die Verbindung ist.

Da das Ganze für beide Übertragungsrichtungen gilt, halte ich das mal allgemein.

Es ergibt keinen Sinn, die Übertragung mehrerer Dateien parallel auszuführen, wenn bereits eine Übertragung die Bandbreite voll beansprucht.
Desweiteren ist es sinnlos, mehrere Übertragungen zu starten, wenn dadurch der Durchsatz einer nicht ausgelasteten Leitung nicht steigt. Dann kann der Partner nämlich nicht mehr verarbeiten (andere Nutzer oder Geschwindigkeitsproblem) und die Aufteilung verursacht nur Verzögerungen für die Verwaltung.

Parallel übertragen ergibt nur dann Sinn, wenn Verbindungen zu mehreren Partnern bestehen und eine Verbindung die Bandbreite der Leitung nicht voll ausnutzen kann.

Gruß

Dietmar Brüggendiek

[Sanchez]

Einen schönen Ansatzpunkt für die Verwaltung eines Thread-Pools findest du im BDN:
http://bdn.borland.com/article/0,1410,30027,00.html

grüße, daniel

[nailor]

unter normalen bedingungen bist du am schnellsten dran, wenn du eins auf einmal runterlädst und mit dem download des nächsten kurz vor ende des letzen beginnst, um pausen zu vermeiden. (das ist für den fall, dass die verbindung bremst). wenn der eigene rechner bremst, ist es eigentlich egal, nur wie o.g. pausen verhindern. wenn der andere rechner bremst sind jegliche "umgehungsversuche" nicht unterstützenswert und daher auch o.g. prinzip am sinnvollsten.