Funktioniert das parallele Entpacken?

In einem früheren Beitrag hatte ich den Versuch, ein Unzip-Dienstprogramm zu schreiben, das Dateien parallel entpackt, auf der Grundlage, dass Rust diesen Versuch sicher macht.

Hier sind einige Leistungsergebnisse.

Der Anwendungsfall, der mir am Herzen liegt, ist das Entpacken der Chromium ASAN-Builds, die hier erhältlich sind . Für diese Tests habe ich einen bestimmten Build ausgewählt, der zufällig 3.845.117.901 Byte groß ist.

ripunzipUnterstützt jetzt zwei Modi: ripunzip file <filename>, und ripunzip uri <URI>. Ersteres entpackt einfach eine Datei. Letzteres verwendet mehrere HTTP-Bereichsanforderungen, um den Download und das Entpacken parallel durchzuführen. (Bereichsanfragen sind aufgrund der Struktur einer ZIP-Datei erforderlich – sie muss die über die gesamte Datei verteilten Verzeichnisinformationen lesen, bevor sie mit der tatsächlichen Dekomprimierung des Inhalts beginnen kann.)

(unter Verwendung von ripunzipSHA ca71fa12e7510b9d48b55ccd6a9dfe051291ca42. Diese Ergebnisse wurden nicht wiederholt, um statistisch gültig zu sein, da ich den Quell-HTTP-Server nicht zu stark belasten möchte. Es gibt einige offizielle cargo criterionBenchmarks im Projekt, aber sie repräsentieren das reale Netzwerk nicht angemessen Bedingungen).

Hier gibt es einige interessante Ergebnisse!

Zuerst die gute Nachricht zum Entpacken von Dateien: Das Entpacken dieser ZIP-Datei auf einer schnellen Linux-VM dauert 9 Sekunden , im Gegensatz zum Entpacken, das 94 Sekunden dauert. Auf einer Windows-VM sind es 52 Sekunden im Gegensatz zu 165 Sekunden bei 7z.

Allerdings ist diese Verbesserung nicht universell. Auf einer langsamen Linux-VM ripunzipist es tatsächlich langsamer. Ich kann das nicht vollständig erklären – es scheint etwas damit zu tun zu haben, dass das Speicher-Backend des VM-Systems Schwierigkeiten hat, mit vielen parallelen Anfragen fertig zu werden – vielleicht sind es tatsächlich physische Festplattenköpfe, die irgendwo in der Cloud suchen? (Wow. Ich hatte nicht damit gerechnet, dass dieses Tool für altmodische Metallbrocken effizient arbeiten muss.) Ich bin mir nicht sicher, ob das die Erklärung ist, aber es scheint etwas mit der langsamen Schreibgeschwindigkeit zu tun zu haben.

Beim direkten Entpacken von einem URI sehen wir im Allgemeinen, dass ripunzipdie Bandbreite begrenzt zu sein scheint. Auf eine gute Art und Weise! Wir schließen das Entpacken in nur wenigen Sekunden ab, als es zum Herunterladen der ZIP-Datei mit überhaupt gedauert hätte curl, sodass wir das Entpacken praktisch „kostenlos“ erhalten. Dies gilt nicht für Windows, möglicherweise weil ich Chrome verwendet habe, um die ZIP-Datei herunterzuladen ( curlwar nicht verfügbar). Allerdings ist die Entpackgeschwindigkeit auf diesem Windows-Rechner so viel schneller, dass sie immer noch von Vorteil ist.

Ein besonders interessanter Punkt ist, dass das ripunzip urischneller geht als ripunzip fileauf der langsamen Linux-VM … Ich denke, die Suche nach Festplattenköpfen zwischen der ZIP-Datei und den entpackten Dateien ist wirklich sehr langsam, wohingegen das Lesen von einem Remote-HTTP-Server tatsächlich schneller (!) ist.

Was bedeutet das für Chromies, die Sicherheitslücken reproduzieren? Nun, ich muss das Tool packen und in allen unseren Testumgebungen verfügbar machen, aber insgesamt bedeutet das, dass pro Chromium-Build, den wir herunterladen müssen, ein oder zwei Minuten gespart werden … (solange Sie eine SSD verwenden?) Das ist es tatsächlich ist wichtig, wenn wir mehrere Builds mehrmals am Tag herunterladen müssen. Es wird interessant sein zu sehen, ob sich diese Ergebnisse auf die 36-GB-UBSAN-Builds übertragen lassen und ob dieses Tool auch einige unserer automatisierten Systeme schneller machen kann. (Ich denke, ich werde ziemlich schnell herausfinden, ob diese Systeme durch SSDs oder Festplatten gesichert sind…)

Das alles können Sie mit ausprobieren cargo install ripunzip.