seaweedfs
3.80
SeaweedFS ist ein unabhängiges, von Apache lizenziertes Open-Source-Projekt, dessen kontinuierliche Weiterentwicklung ausschließlich der Unterstützung dieser großartigen Unterstützer zu verdanken ist. Wenn Sie SeaweedFS noch stärker machen möchten, denken Sie bitte darüber nach, unseren Sponsoren auf Patreon beizutreten.
Ich und andere Unterstützer werden Ihre Unterstützung sehr zu schätzen wissen!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed oder weed.exe . Oder führen Sie go install github.com/seaweedfs/seaweedfs/weed@latest aus.weed server -dir=/some/data/dir -s3 aus, um einen Master, einen Volume-Server, einen Filer und ein S3-Gateway zu starten. Um die Kapazität zu erhöhen, fügen Sie einfach weitere Volume-Server hinzu, indem Sie weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 lokal oder auf einem anderen Computer ausführen Tausende von Maschinen. Das ist es!
SeaweedFS ist ein einfaches und hoch skalierbares verteiltes Dateisystem. Es gibt zwei Ziele:
SeaweedFS begann als Objektspeicher zur effizienten Verarbeitung kleiner Dateien. Anstatt alle Dateimetadaten in einem zentralen Master zu verwalten, verwaltet der zentrale Master nur Volumes auf Volume-Servern, und diese Volume-Server verwalten Dateien und ihre Metadaten. Dies entlastet den zentralen Master vom Parallelitätsdruck und verteilt Dateimetadaten auf Volume-Server, was einen schnelleren Dateizugriff ermöglicht (O(1), normalerweise nur ein Festplattenlesevorgang).
Für die Metadaten jeder Datei fallen nur 40 Byte Festplattenspeicher-Overhead an. Das Lesen von O(1)-Festplatten ist so einfach, dass Sie die Leistung gerne mit Ihren tatsächlichen Anwendungsfällen testen können.
SeaweedFS begann mit der Implementierung des Haystack-Designpapiers von Facebook. Außerdem implementiert SeaweedFS Erasure Coding mit Ideen von f4: Facebooks Warm BLOB Storage System und weist viele Ähnlichkeiten mit Facebooks Tectonic Filesystem auf
Zusätzlich zum Objektspeicher kann der optionale Filer Verzeichnisse und POSIX-Attribute unterstützen. Filer ist ein separater linear skalierbarer zustandsloser Server mit anpassbaren Metadatenspeichern, z. B. MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB usw.
Bei allen verteilten Schlüsselwertspeichern können die großen Werte nach SeaweedFS ausgelagert werden. Dank der schnellen Zugriffsgeschwindigkeit und der linear skalierbaren Kapazität kann SeaweedFS als verteilter Key-Large-Value-Speicher fungieren.
SeaweedFS kann transparent in die Cloud integriert werden. Mit Hot-Daten im lokalen Cluster und Warm-Daten in der Cloud mit O(1)-Zugriffszeit kann SeaweedFS sowohl schnelle lokale Zugriffszeit als auch elastische Cloud-Speicherkapazität erreichen. Darüber hinaus werden die Kosten für die Cloud-Speicherzugriffs-API minimiert. Schneller und günstiger als direkter Cloud-Speicher!
Zurück zum Inhaltsverzeichnis
Zurück zum Inhaltsverzeichnis
Zurück zum Inhaltsverzeichnis
Standardmäßig läuft der Master-Knoten auf Port 9333 und die Volume-Knoten auf Port 8080. Starten wir einen Master-Knoten und zwei Volume-Knoten auf Port 8080 und 8081. Idealerweise sollten sie von verschiedenen Maschinen aus gestartet werden. Wir verwenden localhost als Beispiel.
SeaweedFS verwendet HTTP-REST-Operationen zum Lesen, Schreiben und Löschen. Die Antworten liegen im JSON- oder JSONP-Format vor.
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
So laden Sie eine Datei hoch: Senden Sie zunächst eine HTTP-POST-, PUT- oder GET-Anfrage an /dir/assign um eine fid und eine Volume-Server-URL zu erhalten:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Zweitens, um den Dateiinhalt zu speichern, senden Sie aus der Antwort eine mehrteilige HTTP-POST-Anfrage an url + '/' + fid :
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Senden Sie zum Aktualisieren eine weitere POST-Anfrage mit aktualisiertem Dateiinhalt.
Senden Sie zum Löschen eine HTTP-DELETE-Anfrage an dieselbe url + '/' + fid -URL:
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Jetzt können Sie die fid , in diesem Fall 3,01637037d6, in einem Datenbankfeld speichern.
Die Zahl 3 am Anfang stellt eine Volume-ID dar. Nach dem Komma sind es ein Dateischlüssel, 01, und ein Dateicookie, 637037d6.
Die Volume-ID ist eine vorzeichenlose 32-Bit-Ganzzahl. Der Dateischlüssel ist eine vorzeichenlose 64-Bit-Ganzzahl. Das Datei-Cookie ist eine vorzeichenlose 32-Bit-Ganzzahl, die verwendet wird, um das Erraten von URLs zu verhindern.
Der Dateischlüssel und das Datei-Cookie sind beide hexadezimal codiert. Sie können das Tupel <Volume-ID, Dateischlüssel, Datei-Cookie> in Ihrem eigenen Format speichern oder die fid einfach als Zeichenfolge speichern.
Bei einer Speicherung als String würden Sie theoretisch 8+1+16+8=33 Bytes benötigen. Ein char(33) würde ausreichen, wenn nicht sogar mehr als genug, da die meisten Anwendungen keine 2^32 Volumes benötigen.
Wenn der Platz wirklich ein Problem ist, können Sie die Datei-ID in Ihrem eigenen Format speichern. Sie benötigen eine 4-Byte-Ganzzahl für die Volume-ID, eine 8-Byte-lange Zahl für den Dateischlüssel und eine 4-Byte-Ganzzahl für das Dateicookie. 16 Bytes sind also mehr als genug.
Hier ist ein Beispiel für die Darstellung der URL.
Suchen Sie zunächst anhand der Volume-ID der Datei nach den URLs des Volume-Servers:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Da es (normalerweise) nicht allzu viele Volume-Server gibt und Volumes nicht oft verschoben werden, können Sie die Ergebnisse meistens zwischenspeichern. Abhängig vom Replikationstyp kann ein Volume mehrere Replikatstandorte haben. Wählen Sie einfach zufällig einen Ort zum Lesen aus.
Jetzt können Sie die öffentliche URL übernehmen, die URL rendern oder direkt per URL vom Volume-Server lesen:
http://localhost:8080/3,01637037d6.jpg
Beachten Sie, dass wir hier die Dateierweiterung „.jpg“ hinzufügen. Dies ist optional und nur eine Möglichkeit für den Client, den Dateiinhaltstyp anzugeben.
Wenn Sie eine schönere URL wünschen, können Sie eines dieser alternativen URL-Formate verwenden:
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
Wenn Sie eine skalierte Version eines Bildes erhalten möchten, können Sie einige Parameter hinzufügen:
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS wendet die Replikationsstrategie auf Volume-Ebene an. Wenn Sie also eine Datei-ID erhalten, können Sie die Replikationsstrategie angeben. Zum Beispiel:
curl http://localhost:9333/dir/assign?replication=001
Die Replikationsparameteroptionen sind:
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
Weitere Details zur Replikation finden Sie im Wiki.
Sie können beim Starten des Masterservers auch die Standardreplikationsstrategie festlegen.
Volume-Server können mit einem bestimmten Rechenzentrumsnamen gestartet werden:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
Beim Anfordern eines Dateischlüssels kann ein optionaler „dataCenter“-Parameter das zugewiesene Volumen auf das spezifische Rechenzentrum beschränken. Dies gibt beispielsweise an, dass das zugewiesene Volume auf „dc1“ begrenzt werden soll:
http://localhost:9333/dir/assign?dataCenter=dc1
Zurück zum Inhaltsverzeichnis
Normalerweise teilen verteilte Dateisysteme jede Datei in Blöcke auf. Ein zentraler Master verwaltet die Zuordnung der Dateinamen, der Blockindizes zu den Blockhandles und auch der Blöcke, über die jeder Blockserver verfügt.
Der Hauptnachteil besteht darin, dass der zentrale Master viele kleine Dateien nicht effizient verarbeiten kann und da alle Leseanforderungen über den Chunk-Master laufen müssen, ist die Skalierung für viele gleichzeitige Benutzer möglicherweise nicht gut.
Anstatt Chunks zu verwalten, verwaltet SeaweedFS Datenmengen im Masterserver. Jedes Datenvolumen ist 32 GB groß und kann viele Dateien enthalten. Und jeder Speicherknoten kann viele Datenvolumes haben. Der Masterknoten muss also nur die Metadaten zu den Volumes speichern, was eine relativ kleine Datenmenge darstellt und im Allgemeinen stabil ist.
Die tatsächlichen Dateimetadaten werden in jedem Volume auf Volume-Servern gespeichert. Da jeder Volume-Server nur Metadaten von Dateien auf seiner eigenen Festplatte verwaltet, mit nur 16 Bytes für jede Datei, kann jeder Dateizugriff Dateimetadaten nur aus dem Speicher lesen und erfordert nur einen Festplattenvorgang, um Dateidaten tatsächlich zu lesen.
Bedenken Sie zum Vergleich, dass eine xfs-Inode-Struktur unter Linux 536 Byte groß ist.
Die Architektur ist ziemlich einfach. Die eigentlichen Daten werden in Volumes auf Speicherknoten gespeichert. Ein Volume-Server kann über mehrere Volumes verfügen und sowohl Lese- als auch Schreibzugriff mit Basisauthentifizierung unterstützen.
Alle Volumes werden von einem Master-Server verwaltet. Der Master-Server enthält die Volume-ID zur Volume-Server-Zuordnung. Dabei handelt es sich um relativ statische Informationen, die leicht zwischengespeichert werden können.
Bei jeder Schreibanforderung generiert der Masterserver außerdem einen Dateischlüssel, bei dem es sich um eine wachsende 64-Bit-Ganzzahl ohne Vorzeichen handelt. Da Schreibanfragen im Allgemeinen nicht so häufig sind wie Leseanfragen, sollte ein Master-Server in der Lage sein, die Parallelität gut zu bewältigen.
Wenn ein Client eine Schreibanforderung sendet, gibt der Master-Server (Volume-ID, Dateischlüssel, Datei-Cookie, Volume-Knoten-URL) für die Datei zurück. Der Client kontaktiert dann den Volume-Knoten und sendet den Dateiinhalt per POST.
Wenn ein Client eine Datei basierend auf (Volume-ID, Dateischlüssel, Datei-Cookie) lesen muss, fragt er den Master-Server anhand der Volume-ID nach (URL des Volume-Knotens, öffentliche URL des Volume-Knotens) oder ruft diese aus einem Cache ab. Dann kann der Client den Inhalt ERHALTEN oder einfach die URL auf Webseiten rendern und den Browser den Inhalt abrufen lassen.
Einzelheiten zum Schreib-Lese-Vorgang finden Sie im Beispiel.
In der aktuellen Implementierung kann jedes Volume 32 Gibibyte (32 GB oder 8 x 2 ^ 32 Byte) enthalten. Dies liegt daran, dass wir den Inhalt auf 8 Byte ausrichten. Wir können dies leicht auf 64 GB oder 128 GB oder mehr erhöhen, indem wir zwei Codezeilen ändern, allerdings auf Kosten des durch die Ausrichtung verschwendeten Füllraums.
Es können 4 Gibibyte (4GiB oder 2^32 Byte) an Volumes vorhanden sein. Die Gesamtsystemgröße beträgt also 8 x 4GiB x 4GiB, was 128 Exbibytes (128EiB oder 2^67 Bytes) entspricht.
Die Größe jeder einzelnen Datei ist auf die Volumegröße beschränkt.
Alle auf einem Volume-Server gespeicherten Datei-Metainformationen sind ohne Festplattenzugriff aus dem Speicher lesbar. Jede Datei benötigt nur einen 16-Byte-Map-Eintrag mit <64-Bit-Schlüssel, 32-Bit-Offset, 32-Bit-Größe>. Natürlich hat jeder Karteneintrag seine eigenen Platzkosten für die Karte. Aber normalerweise geht der Speicherplatz auf der Festplatte aus, bevor der Speicher erschöpft ist.
Die lokalen Volume-Server sind viel schneller, während Cloud-Speicher über eine elastische Kapazität verfügen und tatsächlich kosteneffizienter sind, wenn nicht häufig darauf zugegriffen wird (das Hochladen ist normalerweise kostenlos, der Zugriff jedoch relativ kostspielig). Mit der Nur-Anhängen-Struktur und der O(1)-Zugriffszeit kann SeaweedFS sowohl den lokalen als auch den Cloud-Speicher nutzen, indem es die warmen Daten in die Cloud verlagert.
Normalerweise sind heiße Daten frisch und warme Daten alt. SeaweedFS legt die neu erstellten Volumes auf lokalen Servern ab und lädt die älteren Volumes optional in die Cloud hoch. Wenn seltener auf die älteren Daten zugegriffen wird, erhalten Sie buchstäblich unbegrenzte Kapazität mit begrenzten lokalen Servern und trotzdem schnell für neue Daten.
Mit der O(1)-Zugriffszeit werden die Netzwerklatenzkosten auf einem Minimum gehalten.
Wenn die heißen/warmen Daten im Verhältnis 20/80 aufgeteilt werden, können Sie mit 20 Servern eine Speicherkapazität von 100 Servern erreichen. Das ist eine Kostenersparnis von 80 %! Oder Sie können die 80 Server auch zum Speichern neuer Daten umfunktionieren und so den fünffachen Speicherdurchsatz erzielen.
Zurück zum Inhaltsverzeichnis
Die meisten anderen verteilten Dateisysteme scheinen komplizierter als nötig zu sein.
SeaweedFS soll schnell und einfach sein, sowohl bei der Einrichtung als auch bei der Bedienung. Wenn Sie hier nicht verstehen, wie es funktioniert, haben wir versagt! Bitte stellen Sie bei Fragen ein Problem oder aktualisieren Sie diese Datei mit Erläuterungen.
SeaweedFS entwickelt sich ständig weiter. Dasselbe gilt auch für andere Systeme. Diese Vergleiche können schnell veraltet sein. Bitte helfen Sie, sie auf dem neuesten Stand zu halten.
Zurück zum Inhaltsverzeichnis
HDFS verwendet den Chunk-Ansatz für jede Datei und eignet sich ideal zum Speichern großer Dateien.
SeaweedFS ist ideal für die schnelle und gleichzeitige Bereitstellung relativ kleinerer Dateien.
SeaweedFS kann auch besonders große Dateien speichern, indem es sie in überschaubare Datenblöcke aufteilt und die Datei-IDs der Datenblöcke in einem Meta-Block speichert. Dies wird durch das Tool „Weed-Upload/Download“ verwaltet, und der Weed-Master oder die Volume-Server sind sich dessen nicht bewusst.
Zurück zum Inhaltsverzeichnis
Die Architekturen sind größtenteils gleich. SeaweedFS zielt darauf ab, Dateien mit einer einfachen und flachen Architektur schnell zu speichern und zu lesen. Die Hauptunterschiede sind
| System | Dateimetadaten | Dateiinhalt gelesen | POSIX | REST-API | Optimiert für eine große Anzahl kleiner Dateien |
|---|---|---|---|---|---|
| AlgenFS | Lookup-Volume-ID, zwischenspeicherbar | O(1) Festplattensuche | Ja | Ja | |
| SeaweedFS Filer | Linear skalierbar, anpassbar | O(1) Festplattensuche | SICHERUNG | Ja | Ja |
| GlusterFS | Hashing | SICHERUNG, NFS | |||
| Ceph | Hashing + Regeln | SICHERUNG | Ja | ||
| MooseFS | in Erinnerung | SICHERUNG | NEIN | ||
| MinIO | separate Metadatei für jede Datei | Ja | NEIN |
Zurück zum Inhaltsverzeichnis
GlusterFS speichert Dateien, sowohl Verzeichnisse als auch Inhalte, in konfigurierbaren Volumes, die „Bricks“ genannt werden.
GlusterFS hasht den Pfad und den Dateinamen in IDs, weist sie virtuellen Volumes zu und ordnet sie dann „Bricks“ zu.
Zurück zum Inhaltsverzeichnis
MooseFS vernachlässigt das Problem kleiner Dateien. Aus dem Moosefs 3.0-Handbuch geht hervor, dass „selbst eine kleine Datei 64 KB plus zusätzlich 4 KB Prüfsummen und 1 KB für den Header belegt“, da sie „ursprünglich für die Aufbewahrung großer Mengen (z. B. mehrere Tausend) sehr großer Dateien konzipiert war“.
Der MooseFS Master Server behält alle Metadaten im Speicher. Gleiches Problem wie beim HDFS-Namensknoten.
Zurück zum Inhaltsverzeichnis
Ceph kann ähnlich wie SeaweedFS als Schlüssel->Blob-Speicher eingerichtet werden. Es ist viel komplizierter, da darüberliegende Stützschichten erforderlich sind. Hier ist ein detaillierterer Vergleich
SeaweedFS verfügt über eine zentralisierte Master-Gruppe, um nach freien Volumes zu suchen, während Ceph Hashing- und Metadatenserver verwendet, um seine Objekte zu lokalisieren. Ein zentraler Master erleichtert die Codierung und Verwaltung.
Ceph basiert wie SeaweedFS auf dem Objektspeicher RADOS. Ceph ist mit gemischten Rezensionen ziemlich kompliziert.
Ceph verwendet CRUSH-Hashing, um die Datenplatzierung automatisch zu verwalten und so die Daten effizient zu lokalisieren. Die Daten müssen jedoch gemäß dem CRUSH-Algorithmus platziert werden. Jede falsche Konfiguration würde zu Datenverlust führen. Topologieänderungen, wie das Hinzufügen neuer Server zur Erhöhung der Kapazität, führen zu einer Datenmigration mit hohen E/A-Kosten, um den CRUSH-Algorithmus zu erfüllen. SeaweedFS platziert Daten, indem es sie beliebigen beschreibbaren Volumes zuweist. Wenn das Schreiben auf ein Volume fehlschlägt, wählen Sie einfach ein anderes Volume zum Schreiben aus. Auch das Hinzufügen weiterer Volumes ist denkbar einfach.
SeaweedFS ist für kleine Dateien optimiert. Kleine Dateien werden als ein zusammenhängender Inhaltsblock gespeichert, mit höchstens 8 ungenutzten Bytes zwischen den Dateien. Der Zugriff auf kleine Dateien erfolgt über das Lesen von O(1)-Festplatten.
SeaweedFS Filer verwendet Standardspeicher wie MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, um Dateiverzeichnisse zu verwalten. Diese Geschäfte sind bewährt, skalierbar und einfacher zu verwalten.
| AlgenFS | vergleichbar mit Ceph | Vorteil |
|---|---|---|
| Master | MDS | einfacher |
| Volumen | OSD | optimiert für kleine Dateien |
| Filer | Ceph FS | linear skalierbar, anpassbar, O(1) oder O(logN) |
Zurück zum Inhaltsverzeichnis
MinIO orientiert sich eng an AWS S3 und eignet sich ideal zum Testen der S3-API. Es verfügt über eine gute Benutzeroberfläche, Richtlinien, Versionierungen usw. SeaweedFS versucht hier aufzuholen. Es ist auch möglich, MinIO später als Gateway vor SeaweedFS zu platzieren.
MinIO-Metadaten liegen in einfachen Dateien vor. Jeder Dateischreibvorgang führt zu zusätzlichen Schreibvorgängen in der entsprechenden Metadatei.
MinIO bietet keine Optimierung für viele kleine Dateien. Die Dateien werden einfach unverändert auf lokalen Festplatten gespeichert. Hinzu kommt die zusätzliche Metadatei und die Shards für die Erasure-Codierung, was das LOSF-Problem nur noch verstärkt.
MinIO verfügt über mehrere Festplatten-E/A zum Lesen einer Datei. SeaweedFS verfügt über O(1)-Lesevorgänge auf der Festplatte, sogar für Erasure-Coded-Dateien.
MinIO verfügt über eine Vollzeit-Löschcodierung. SeaweedFS nutzt die Replikation auf Hot-Daten für eine schnellere Geschwindigkeit und wendet optional Erasure Coding auf Warm-Daten an.
MinIO bietet keine POSIX-ähnliche API-Unterstützung.
MinIO stellt spezielle Anforderungen an das Speicherlayout. Es ist nicht flexibel, die Kapazität anzupassen. Starten Sie in SeaweedFS einfach einen Volume-Server, der auf den Master verweist. Das ist alles.
Das ist ein superspannendes Projekt! Und wir brauchen Helfer und Unterstützung!
Zurück zum Inhaltsverzeichnis
Installationsanleitung für Benutzer, die mit Golang nicht vertraut sind
Schritt 1: Installieren Sie go auf Ihrem Computer und richten Sie die Umgebung ein, indem Sie den Anweisungen unter folgen:
https://golang.org/doc/install
Stellen Sie sicher, dass Sie Ihren $GOPATH definieren
Schritt 2: Schauen Sie sich dieses Repo an:
git clone https://github.com/seaweedfs/seaweedfs.gitSchritt 3: Laden Sie das Projekt herunter, kompilieren und installieren Sie es, indem Sie den folgenden Befehl ausführen
cd seaweedfs/weed && make install Sobald dies erledigt ist, finden Sie die ausführbare Datei „weed“ in Ihrem $GOPATH/bin -Verzeichnis
Zurück zum Inhaltsverzeichnis
Beim Testen der Leseleistung auf SeaweedFS handelt es sich im Grunde genommen um einen Leistungstest der zufälligen Lesegeschwindigkeit Ihrer Festplatte. Festplatten erreichen normalerweise 100 MB/s bis 200 MB/s.
Um kleine Dateien zu ändern oder zu löschen, muss die SSD jeweils einen ganzen Block löschen und Inhalte in vorhandenen Blöcken in einen neuen Block verschieben. SSDs sind schnell, wenn sie ganz neu sind, werden aber mit der Zeit fragmentiert und Sie müssen Blöcke durch Müllsammeln sammeln und komprimieren. SeaweedFS ist SSD-freundlich, da es nur angehängt werden kann. Das Löschen und Komprimieren erfolgt auf Volume-Ebene im Hintergrund, wodurch der Lesevorgang nicht verlangsamt und keine Fragmentierung verursacht wird.
Zurück zum Inhaltsverzeichnis
Meine eigenen unwissenschaftlichen Einzelmaschinenergebnisse auf einem MacBook mit Solid State Disk, CPU: 1 Intel Core i7 2,6 GHz.
Schreiben Sie eine Million 1-KB-Datei:
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
1 Million Dateien zufällig lesen:
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
Um segmentierte Anforderungsstatistiken anzuzeigen, verwenden Sie den Parameter --analyze.v.
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
Zurück zum Inhaltsverzeichnis
Lizenziert unter der Apache-Lizenz, Version 2.0 (die „Lizenz“); Sie dürfen diese Datei nur in Übereinstimmung mit der Lizenz verwenden. Eine Kopie der Lizenz erhalten Sie unter
http://www.apache.org/licenses/LICENSE-2.0
Sofern nicht gesetzlich vorgeschrieben oder schriftlich vereinbart, wird die im Rahmen der Lizenz vertriebene Software „WIE BESEHEN“ und OHNE GEWÄHRLEISTUNGEN ODER BEDINGUNGEN JEGLICHER ART, weder ausdrücklich noch stillschweigend, vertrieben. Die spezifische Sprache, die die Berechtigungen und Einschränkungen im Rahmen der Lizenz regelt, finden Sie in der Lizenz.
Der Text dieser Seite kann unter den Bedingungen der Creative Commons Attribution-Sharealike 3.0 Unported License und der GNU Free Documentation License geändert und wiederverwendet werden (unversioniert, ohne invariante Abschnitte, Texte auf der Vorderseite oder auf der Rückseite).
Zurück zum Inhaltsverzeichnis
