Objekt-Storage-Vergleich

1. Upload-(PUT)-Leistung

PUT misst den anhaltenden Upload-Durchsatz in MiB/s. Die folgenden Abschnitte trennen sequentielles Verhalten von paralleler Skalierung und zeigen gültige Stichprobenzahlen sowie Mittelwerte an.

1.1 PUT-Durchsatz mit 1 Thread

IDrive^® e2 führte bei allen vier Objektgrößenkategorien bei 1 Thread. Der Durchschnitt reichte von 9,37 MiB/s bei 256 KiB bis 307,30 MiB/s bei 100 MiB.

1.2 PUT-Durchsatz mit 5 Threads

IDrive^® e2 führte bei allen vier Objektgrößenkategorien mit 5 Threads. Der Durchschnitt reichte von 47,71 MiB/s bei 256KiB bis 1.400,18 MiB/s bei 100MiB.

Tests mit fünf Threads stellen ein moderates Maß an Parallelität auf Client-Seite dar und können für Backup-, Synchronisations- und Migrationsanwendungen relevant sein, die mehrere gleichzeitige Übertragungen verwenden.

Die Rangfolge aus dem Ein-Thread-Test blieb auch bei steigender Parallelität gleich. Das bedeutet, dass der Spitzenreiter über alle Objektgrößen hinweg mehr gleichzeitige Uploads verarbeiten konnte und nicht nur einzelne Übertragungen.

1.3 PUT-Durchsatz mit 10 Threads

IDrive^® e2 führte bei allen vier Objektgrößenkategorien mit 10 Threads. Der Durchschnitt reichte von 93,00 MiB/s bei 256 KiB bis 1.879,48 MiB/s bei 100 MiB.

Die Ergebnisse mit zehn Threads sind der stärkste Hinweis auf die aggregierte Upload-Kapazität in dieser Testmatrix. Der PUT-Durchsatz für große Objekte stieg bei allen Anbietern deutlich an, doch das Ausmaß der Skalierung variierte. Diese Werte sind am relevantesten für parallele Backup-, Replikations-, Migrations- und Media-Ingest-Workflows, die mehrere aktive Uploads aufrechterhalten, statt zu warten, bis ein Objekt abgeschlossen ist, bevor das nächste gesendet wird.

1.4 PUT-Parallelitätsskalierung

Die Skalierungskurven zeigen, ob der Durchsatz steigt, wenn weitere Worker von eins bis 10 hinzugefügt werden. Größere Objekte erzielen in der Regel stärkere Zugewinne, weil Verbindungs- und Anforderungs-Overhead eine geringere Rolle spielen. Bei kleinen Objekten hängt die Skalierung vor allem vom Overhead der Anforderungsverarbeitung ab, während sie bei 100MiB-Objekten die anhaltende Übertragungsgeschwindigkeit und die Effizienz der Nutzung paralleler Streams widerspiegelt.

2. Download-(GET)-Leistung

GET misst, wie viele Daten im Laufe der Zeit in MiB/s heruntergeladen werden können. Im Vergleich zu PUT ist der einthreadige GET-Wert zwischen den Anbietern ähnlicher, doch die Unterschiede werden deutlicher, wenn mehr Threads eingesetzt werden.

2.1 GET-Durchsatz mit 1 Thread

Kategori-Spitzenreiter: 256KiB: IDrive^® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive^®e2.

GET mit einem Thread war der umkämpfteste Teil des Tests. Backblaze B2 führte bei den Kategorien 5MiB und 50MiB, während IDrive^® e2 bei 256KiB und 100MiB führte. Die 5MiB-Ergebnisse lagen eng beieinander: Backblaze B2 erreichte im Durchschnitt 64,87 MiB/s, AWS S3 63,36 MiB/s und IDrive^® e2 63,13 MiB/s.

2.2 GET-Durchsatz mit 5 Threads

Kategorie-Spitzenreiter: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: Backblaze B2.

Mit fünf Threads führte Backblaze B2 den 5MiB-GET-Test mit 399,49 MiB/s an, während IDrive^® e2 bei 256KiB, 50MiB und 100MiB führte. Diese gemischten Ergebnisse zeigen, warum es wichtig ist, die Workload-Kategorie zu vergleichen, die zu Ihrer Anwendung passt.

2.3 GET-Durchsatz mit 10 Threads

Kategorie-Spitzenreiter: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: IDrive^® e2.

Mit zehn Threads führte IDrive^® e2 alle vier GET-Größenkategorien an, von 171,43 MiB/s bei 256KiB bis zu 1.034,81 MiB/s bei 100MiB. Das zeigt, dass sein Vorteil mit steigender Parallelität größer wurde.

2.4 GET-Parallelitätsskalierung

Bei 256KiB-Objekten ist der Aufwand für die Anforderungsverarbeitung der wichtigste Faktor. Bei 100MiB-Objekten sind anhaltende Übertragungsgeschwindigkeit und Parallelität wichtiger. Diese beiden Fälle helfen, die Gesamtergebnisse zu interpretieren. Die klareren Unterschiede bei höherer Parallelität sind besonders relevant für Restore-, Content-Delivery- und Analyse-Workloads mit vielen aktiven Leseanforderungen.

3. Anforderungslatenz

Latenz ist die durchschnittliche Zeit, die für den Abschluss einer Anfrage benötigt wird, gemessen mit Warp. Eine niedrigere Latenz bedeutet schnellere Antworten. Es ist wichtig, sowohl den Durchsatz als auch die Latenz zu betrachten, da ein Anbieter zwar einen hohen Gesamtdurchsatz haben kann, aber pro Anfrage dennoch länger benötigt.

Die Latenzdiagramme zeigen jede Objektgröße in einem separaten Bereich, damit die größeren 50MiB- und 100MiB-Werte die kleineren Ergebnisse nicht schwer lesbar machen. Die Anbieternamen bleiben auf der vertikalen Achse fest, und jeder Balken ist mit seinem Wert beschriftet. Dieses Layout hilft beim direkten Vergleich der Ergebnisse, ohne dass man aus Farben oder Balkenlängen schließen muss.

4. Konsistenz

Der Variationskoeffizient, kurz CV, zeigt, wie stark sich die Benchmark-Ergebnisse von Lauf zu Lauf im Vergleich zum Durchschnitt verändert haben. Ein niedrigerer CV bedeutet, dass die Leistung stabiler und vorhersehbarer war, während ein höherer CV auf mehr Schwankungen zwischen den Läufen hinweist.

5. Workload-Interpretation

5.1 Workloads für kleine Objekte

Die 256KiB-Tests konzentrieren sich darauf, wie gut Anbieter Anfragen verarbeiten, Verbindungen wiederverwenden, Metadaten verarbeiten und API-Overhead verwalten. Diese Ergebnisse sind besonders relevant für Backup-Indizes, Thumbnails, kleine App-Assets und Workloads mit vielen kleinen Objekten.

5.2 Workloads mittlerer Größe

Die Tests mit 5MiB und 50MiB repräsentieren typische Backup-Dateien, Mediensegmente, App-Bundles und Analysedateien. Die Ergebnisse zeigen, wie effizient jeder Anbieter bei einzelnen Uploads ist und wie stark parallele Uploads die Gesamtgeschwindigkeit erhöhen können.

5.3 Workloads großer Objekte

Die 100MiB-Tests konzentrieren sich stärker auf stabile Netzwerk- und Dienstdatenübertragung. Ergebnisse mit zehn Threads sind nützlich für parallele Sicherung, Wiederherstellung, Replikation und Datenverschiebung, während die Ein-Thread-Ergebnisse zeigen, was bei einzelnen Übertragungen zu erwarten ist.

5.4 Angemessene Interpretation

Diese Tests basieren auf Ergebnissen eines einzelnen Clients in US East. Sie decken nicht jede Region, jeden Client-Standort, jede Netzroute, jede Tageszeit, jedes SDK oder jedes App-Muster ab. Leser sollten sich vor allem auf die Testfälle konzentrieren, die ihren eigenen Objektgrößen und ihrer Parallelität entsprechen.

6. Ein-Tages-Benchmark für LIST, HEAD und DELETE

LIST, HEAD und DELETE wurden als separate operative Ein-Tages-Benchmarks ausgeführt. Im Gegensatz zu den PUT- und GET-Abschnitten sind diese Werte keine Sieben-Zyklen-Durchschnitte. Jeder Test verwendete denselben Testursprung in US East und 10 gleichzeitige Worker. LIST und DELETE nutzten einen vorbereiteten Satz von 100.000 Objekten, während HEAD 50.000 Objekte als Ziel für die Anfragen verwendete. LIST und HEAD liefen jeweils etwa fünf Minuten. DELETE lief, bis der feste Objektsatz verarbeitet war.

6.1 Testkonfiguration

Bei HEAD stehen "50,000 objects" für den Objektsatz, der für Metadatenanfragen verfügbar war. Warp führte mehr HEAD-Anfragen aus als es einzigartige Objekte gab, da der zeitbasierte Test während des gesamten Laufs weiter Anfragen stellte.

6.2 LIST-Leistung

IDrive^® e2 hatte den höchsten durchschnittlichen LIST-Durchsatz mit 71.467,78 Objekten/s und die niedrigste durchschnittliche LIST-Anforderungslatenz mit 1.409,9 ms. Die durchschnittliche TTFB betrug 14 ms. Diese Zahlen stammen aus einem einzigen Tag und sollten nicht als langfristige Durchschnittswerte verstanden werden.

Die LIST-Leistung hängt von Paginierung, Schlüsseltraversierung, Antwortaufbau und der Fähigkeit des Clients ab, jede Seite zu verarbeiten. Der Durchsatz (Objekte pro Sekunde) zeigt, wie schnell Objekteinträge zurückgegeben wurden, während die durchschnittliche Anforderungslatenz die Zeit pro LIST-Anfrage angibt. TTFB zeigt, wie schnell die ersten Antwortdaten ankamen. Da der Test zeitbasiert war, zeigt das Bereichsdiagramm auch kurzfristige Schwankungen während des Laufs.

6.3 HEAD-Leistung

IDrive^® e2 verzeichnete den höchsten durchschnittlichen HEAD-Durchsatz mit 1.017,80 Objekten/s und die niedrigste durchschnittliche Anforderungslatenz mit 9,8 ms. Backblaze B2 belegte mit 770,76 Objekten/s den zweiten Platz, gefolgt von Wasabi mit 691,42 Objekten/s, AWS S3 mit 475,95 Objekten/s und Cloudflare R2 mit 98,24 Objekten/s. Alle fünf Anbieter beendeten den Test ohne gemeldete Fehler.

6.4 DELETE-Leistung

IDrive^® e2 erreichte den höchsten vergleichbaren DELETE-Durchsatz mit 3.475,88 Objekten/s und die niedrigste durchschnittliche Anforderungslatenz mit 290,43 ms. Cloudflare R2 belegte den zweiten Platz mit einem durchschnittlichen Durchsatz von 2.022,16 Objekten/s und einer Latenz von 495,89 ms, gefolgt von AWS S3 mit 1.032,09 Objekten/s und Wasabi mit 815,72 Objekten/s.

Hinweis: Backblaze B2 wurde aus dem DELETE-Vergleich ausgeschlossen, da B2-Buckets grundsätzlich versioniert sind und keinen herkömmlichen nicht-versionierten Modus unterstützen. Der Standard-DELETE-Benchmark von Warp sendet DELETE-Anforderungen anhand von Namen, ohne einzelne Versions-IDs aufzuzählen und zu löschen. Bei B2 erzeugen solche Anforderungen Löschmarkierungen, anstatt die gespeicherten Objektversionen dauerhaft zu entfernen, wodurch die Ergebnisse für einen direkten Vergleich mit nicht-versionierten DELETE-Vorgängen ungeeignet sind.

6.5 LIST-/HEAD-/DELETE-Vorbehalte

• Dies ist ein Ein-Tages-Vergleich und zeigt keine Konsistenz von Tag zu Tag.
• LIST und HEAD sind zeitbasierte Tests, während DELETE nach der Verarbeitung des festen Objektsatzes abgeschlossen wird. Ihr Durchsatz- und Abschlussverhalten sollte daher getrennt interpretiert werden.
• Seitenspezifisches Paging, die LIST-Implementierung, Delete-Batching, Drosselung und die Bucket-Konfiguration können die Ergebnisse erheblich beeinflussen.
• Diese Werte sind eine Momentaufnahme des getesteten Setups und getrennt von den siebenzyklischen PUT-/GET-Ergebnissen.

7. Methodik und Qualitätskontrollen

7.1 Siebenzyklischer PUT- und GET-Benchmark

Der Benchmark verwendete Warp von einer Vultr-Linux-VM in US East. Jeder Anbieter erhielt dieselben Kombinationen aus Operationen, Objektgrößen, Parallelität und Laufzeiten. Die Matrix umfasste 24 Workload-Konfigurationen pro Anbieter und Zyklus: zwei Operationen, vier Objektgrößen und drei Thread-Stufen. Jede Workload lief fünf Minuten lang.

Jeder Testzyklus behielt dieselben Workload-Dimensionen bei, damit die Ergebnisse von Tag zu Tag auf einer vergleichbaren Grundlage aggregiert werden konnten. PUT und GET wurden unabhängig voneinander bei 256KiB, 5MiB, 50MiB und 100MiB mit 1, 5 und 10 gleichzeitigen Workern ausgewertet. Jede Workload lief fünf Minuten. Dieses Design liefert sowohl sequentielle als auch parallele Beobachtungen, ohne grundsätzlich unterschiedliche Objektgrößen oder Parallelitätsstufen zu einem einzigen Wert zu vermischen.

7.2 Kriterien für gültige Ergebnisse

Ein Ergebnis auf Laufebene wurde aufgenommen, wenn Warp einen vollständigen Abschlussbericht mit einer gültigen numerischen Durchsatzmessung erzeugte. Ein nicht-null Rückgabecode des Wrappers oder ein Wrapper-Timeout machte das Ergebnis nicht automatisch ungültig, wenn Warp den Benchmark bereits abgeschlossen und verwertbare Abschlussstatistiken erzeugt hatte. Läufe wurden ausgeschlossen, wenn kein vollständiges numerisches Endergebnis verfügbar war, einschließlich Fehlern während der Testvorbereitung, Dienst-nicht-verfügbar-Fehlern sowie DNS- oder Netzwerk-Timeouts, die die Ausführung des Benchmarks verhinderten.

7.3 Aggregation

Für jede Anbieter-Workload-Zelle berechnet der Bericht den arithmetischen Mittelwert der gültigen Durchsatzwerte auf Laufebene. Die Stichprobenzahlen variieren dort, wo Ergebnisse ausgeschlossen wurden. Latenzwerte werden aus den gültigen Ergebnissen derselben Workload-Zellen abgeleitet.

Kein fehlendes Ergebnis wird zu Null umgewandelt, weil dies Leistung mit Testabschluss vermischen und den Durchschnitt künstlich senken würde. Stattdessen bleiben ausgeschlossene Ergebnisse in der Stichprobenzahl und in der Verfügbarkeitsberichterstattung sichtbar. Die siebenzyklischen Matrizen in den Anhängen bewahren die Sicht auf die einzelnen Läufe und ermöglichen es den Lesern, die einzelnen Beobachtungen hinter den zusammengefassten Tabellen und Diagrammen zu sehen.

Neun unvollständige Läufe wurden bei Wasabi und Backblaze B2 identifiziert. Drei Wasabi-PUT-Tests erreichten das Warp-Timeout, fünf Backblaze-B2-GET-Tests schlugen fehl, weil der Dienst während der Testvorbereitung nicht verfügbar war, und ein Backblaze-B2-PUT-Test scheiterte wegen eines DNS-Lookup-/I/O-Timeouts.

7.4 Ein-Tages-Benchmark für LIST,HEAD und DELETE

LIST, HEAD und DELETE verwendeten denselben Anbietersatz, denselben Testursprung in US East und dasselbe 10-Worker-Parallelitätsniveau, aber ihre Ausführungsdesigns unterschieden sich. LIST und HEAD waren zeitbasierte Tests, die ungefähr fünf Minuten liefen. DELETE verarbeitete einen festen Objektsatz und endete, wenn dieser Satz abgeschlossen war. Ihre Ergebnisse werden unabhängig dargestellt und nicht mit den siebenzyklischen PUT- und GET-Durchschnitten kombiniert oder zur Erstellung eines Gesamtscores für den Anbieter verwendet.

7.5 Einheiten

• PUT- und GET-Durchsatz: MiB/s.
• LIST-, HEAD- und DELETE-Durchsatz: Objekte/s.
• Anforderungslatenz und TTFB: Millisekunden.

7.6 Vollständige Benchmark-Protokolle

Für Reproduzierbarkeit und unabhängige Prüfung werden die vollständigen Warp-Run-Logs und unterstützenden Benchmark-Artefakte im öffentlichen Repository unten referenziert:

Vollständige Warp-Benchmark-Logs: https://github.com/e2-idrive/s3-benchmark-logs

Das Repository stellt das Material auf Laufebene bereit, das verwendet wurde, um die berichteten Aggregationen zu validieren, ausgeschlossene oder fehlgeschlagene Läufe zu untersuchen und die in diesem Bericht beschriebenen Berechnungen zu reproduzieren.

8. Einschränkungen

• Einzelner Client-Standort und Netzwerkpfad; Ergebnisse können je nach Region, ISP, Cloud oder Unternehmensnetzwerk abweichen.
• Synthetische Workloads: Warp bietet Wiederholbarkeit, bildet aber nicht die gesamte Anforderungsmischung, das SDK-Verhalten, Wiederholungen oder die Verteilung von Objekt-Schlüsseln jeder Anwendung ab.
• Begrenzter Beobachtungszeitraum: PUT und GET erstrecken sich über sieben Zyklen; LIST, HEAD und DELETE sind Ein-Tages-Schnappschüsse.
• Keine Analyse von Kosten, Haltbarkeit, Funktionen, Support oder Egress: Dieser Bericht konzentriert sich auf Leistung.
• Kein Perzentil-Latenzvergleich über alle Diagramme: Zur besseren Lesbarkeit werden Mittelwerte gezeigt; Anwendungen, die empfindlich auf Tail-Latency reagieren, sollten workloadspezifische P95/P99-Tests durchführen.
• Ausgeschlossene Ergebnisse: Die Durchschnitte basieren auf gültigen Stichproben und können über Anbieter und Workload-Zellen hinweg unterschiedliche Stichprobengrößen aufweisen.

Was die Ergebnisse zeigen

In diesem Test in US East führte IDrive^® e2 bei den durchschnittlichen PUT-Workloads und bei 9 von 12 durchschnittlichen GET-Workloads. Backblaze B2 führte das 1-Thread-GET bei 5MiB und 50MiB sowie das 5-Thread-GET bei 5MiB an. Die operativen Ein-Tages-Tests sind von diesen siebenzyklischen Ergebnissen getrennt.

Dieser Bericht erzeugt keinen einzigen Score für jeden Anbieter. Unterschiedliche Anwendungen achten auf unterschiedliche Dinge, etwa Upload, Download, Listing, Löschung, Objektgröße, Parallelität, Latenz, Konsistenz, Standort und Kosten. Die beste Nutzung dieser Ergebnisse besteht darin, den Vorgang und die Workload auszuwählen, die Ihren Anforderungen entsprechen, und anschließend sowohl den Durchschnitt als auch die detaillierten Laufdaten zu vergleichen.