3. curl: mehrere Dateien von einem Server laden

curl: mehrere Dateien von einem Server laden

  • U

    Danke, das ist ja interessant. 100 Downloads gleichzeitig klappen jedes Mal (Code 0). Bei 300 Downloads erhalte ich vereinzelt den Code 6, wenn ich gar 1000 Downloads ausführen will, erhalte ich nahezu bei allen den Code 6.

    Das gleiche Bild, wenn ich bspw. die google Startseite downloaden will.

    Kommt curl nicht bei so vielen Handles klar, oder liegt das am Server?

    0
  • Administrator

    Probier allenfalls mal CURLMOPT_MAXCONNECTS zu setzen und dadurch die maximale Anzahl an Verbindungen zu beschränken. Ebenfalls könnte CURLMOPT_PIPELINING hilfreich sein.

    Grüssli

    0
  • U

    Ich danke dir, mit letzterem funktioniert es.

    Die Geschwindigkeit ist zwar trotzdem noch recht langsam (ca 3 Files pro Sekunde), aber deutlich schneller als vorher. Damit spare ich immerhin schon mal eine Größenordnung in der Zeit. Wenn man jetzt noch parallelisiert, wird es sicher recht flott gehen.

    Vielen Dank!

    0
  • U

    Ich habe das ganze jetzt mal parallelisiert, klappt zwar wunderbar, alle Dateien werden vollständig geladen, egal wie viele es sein sollen, allerdings verstehe ich die resultierende Laufzeit nicht.

    Ich will zum Test 100 nahezu identische Dateien downloaden und die benötigte Zeit messen.
    Wenn ich nur einen Thread benutze, benötige ich dazu ca. 65 Sekunden. Also knapp 2 Dateien pro Sekunde, das ist schon deutlich besser als alle nur mit der Easy-Schnittstelle zu laden.
    Verteile ich die Downloads auf 10 Threads, benötige ich ca. 50 Sekunden, selbst wenn ich 100 Threads nutze und jedem Thread eine Datei zum Downloaden gebe, benötige ich auch hier etwa 50 Sekunden.

    Eine Datei alleine ist in knapp 2 Sekunden heruntergeladen, wieso brauchen dann 100 Threads für jeweils eine Datei ca 50 Sekunden? Liegt es an der Option CURLMOPT_PIPELINING, dass es nur eine Pipeline gibt, die sich alle Threads teilen und daher warten müssen?

    Da die Dateien sehr klein sind (ca 5kB pro Datei), fallen die eigentlichen Downloadzeiten nicht ins Gewicht.

    0
  • Administrator

    Ulf schrieb:

    Liegt es an der Option CURLMOPT_PIPELINING, dass es nur eine Pipeline gibt, die sich alle Threads teilen und daher warten müssen?

    Wenn jeder Thread ein eigenes curl Handle hat, dann denke ich eher nicht, da mir neu wäre, dass curl über die Handle-Grenze hinweg Dinge austauschen kann.

    Ich vermute immer noch, dass es an der Festplatte, bzw. am Betriebsystem liegt. Du hast zwar alles schön parallelisiert, aber z.B. ein CreateFile in der WinAPI führt dazu, dass deine Threads synchronisiert werden, da dies jeweils nur einer nach dem anderen machen kann. Auch sind gerade solche Operationen meistens nicht sehr billig.

    Kürzlich hatte ich einen Fall auf Linux, wo ich ebenfalls viele kleine Dateien erstellen und beschreiben musste. Da brachte ebenfalls nicht einmal eine RAMDisk wesentliche Verbesserungen in der Geschwindigkeit, einfach weil das OS selbst viel zu stark gebremst hat.

    Probier mal die Dateien nicht zu schreiben. Also einfach nur herunterladen und die Daten gleich wieder verwerfen. Keine neuen Dateien erstellen und auch keine Daten in diese Dateien schreiben.

    Grüssli

    0
  • U

    Ich konnte keine signifikante Änderung erkennen, wenn ich die Platte komplett außen vor lasse. Aber ich wüsste nicht, wieso das so sein soll. Wenn eine SSD für 100 Dateien zu je 5kB ein paar Sekunden braucht, dann ist die aber schon längst ein Garantiefall 😉

    Beim letztem Benchmark hat 4K-Schreibtest ordentliche >30MB/s ergeben. Die 100 Dateien sollten also in ein paar Millisekunden geschrieben worden sein.

    0
  • U

    Hat niemand eine Idee, woran das liegen könnte?

    Wenn ich auf curl verzichten würde und selbst mittels Sockets den Dateitransfer starte, weiß jemand, ob es dann ähnliche Effekte gibt? Falls nein, könnte man sich ja überlegen, das vielleicht ohne curl zu realisieren.

    0
  • Administrator

    Ulf schrieb:

    Hat niemand eine Idee, woran das liegen könnte?

    Das Problem dürfte sein, dass es ein munteres Rätselraten ist. Mich würde es erstaunen, wenn es an curl liegt, weil ich hatte damit nie irgendwelche Geschwindigkeitsprobleme. Meine Vermutung war das Betriebsystem und das Dateisystem. Daher spielt es auch keine Rolle, dass du eien SSD hast. Wie gesagt, ich hatte das Problem sogar mit einer RAMDisk festgestellt, aber die Rahmenbedingungen sind wohl doch zu unterschiedlich.

    Von daher kann es von meiner Seite aus alles mögliche sein. Ich habe kurz auf der Mailing Liste von curl gesucht, konnte aber nur eine Diskussion in den letzten Jahren über zu langsamen Download finden.

    Grüssli

    0
  • O

    ist der Server gedrosselt?

    0
  • U

    Nein, das ist unabhängig vom Server. Selbst wenn ich spaßenshalber eine Seite vom google-Server nehme, dauert das recht lang, obwohl die Zeiten dort schon viel kleiner sind (habe jetzt keinen genauen Zahlen mehr im Kopf, aber das ging ca 25% schneller). Trotzdem kann ich auch mit schnellen google-Servern nicht ansatzweise meine Bandbreite ausnutzen, die Threads trödeln vor sich hin

    0
Anmelden zum Antworten