Confronto tra object storage

1. Prestazioni di upload (PUT)

PUT misura il throughput di upload sostenuto in MiB/s. Le sezioni seguenti separano il comportamento sequenziale dalla scalabilità concorrente e mostrano il numero di campioni validi insieme alle medie.

1.1 Throughput PUT a 1 thread

IDrive^® e2 ha guidato tutte e quattro le categorie di dimensione degli oggetti a 1 thread. La sua media è andata da 9,37 MiB/s a 256 KiB a 307,30 MiB/s a 100 MiB.

1.2 Throughput PUT a 5 thread

IDrive^® e2 ha guidato tutte e quattro le categorie di dimensione degli oggetti a 5 thread. La sua media è andata da 47,71 MiB/s a 256KiB a 1.400,18 MiB/s a 100MiB.

Il test a cinque thread rappresenta un livello moderato di parallelismo lato client e può essere rilevante per applicazioni di backup, sincronizzazione e migrazione che utilizzano più trasferimenti simultanei.

Le classifiche osservate con un thread sono rimaste le stesse all'aumentare della concorrenza. Ciò significa che il miglior performer ha gestito più upload simultanei su tutte le dimensioni degli oggetti, non solo trasferimenti singoli.

1.3 Throughput PUT a 10 thread

IDrive^® e2 ha guidato tutte e quattro le categorie di dimensione degli oggetti a 10 thread. La sua media è andata da 93,00 MiB/s a 256 KiB a 1.879,48 MiB/s a 100 MiB.

I risultati a dieci thread sono l'indicazione più forte della capacità di upload aggregata in questa matrice di test. Il throughput PUT per gli oggetti di grandi dimensioni è aumentato in modo sostanziale per tutti i provider, ma l'entità della scalabilità è variata. Questi valori sono più rilevanti per flussi di lavoro di backup, replica, migrazione e ingest multimediale paralleli che mantengono attivi più upload invece di attendere il completamento di un oggetto prima di inviare il successivo.

1.4 Scalabilità della concorrenza PUT

Le curve di scalabilità mostrano se il throughput aumenta man mano che vengono aggiunti più worker, da uno a 10. Gli oggetti più grandi di solito vedono guadagni maggiori perché l'overhead di connessione e richiesta pesa meno. Per gli oggetti piccoli, la scalabilità dipende soprattutto dall'overhead di elaborazione delle richieste, mentre per gli oggetti da 100MiB riflette la velocità di trasferimento sostenuta e quanto bene vengono utilizzati i flussi concorrenti.

2. Prestazioni di download (GET)

GET misura quanta quantità di dati può essere scaricata nel tempo, in MiB/s. Rispetto a PUT, il GET a thread singolo è più simile tra i provider, ma le differenze diventano più evidenti quando vengono usati più thread.

2.1 Throughput GET a 1 thread

Leader di categoria: 256KiB: IDrive^® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive^®e2.

Il GET a thread singolo è stata la parte più competitiva del test. Backblaze B2 ha guidato nelle categorie 5MiB e 50MiB, mentre IDrive^® e2 ha guidato in 256KiB e 100MiB. I risultati a 5MiB erano ravvicinati: Backblaze B2 ha registrato in media 64,87 MiB/s, AWS S3 63,36 MiB/s e IDrive^® e2 63,13 MiB/s.

2.2 Throughput GET a 5 thread

Leader di categoria: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: Backblaze B2.

Con cinque thread, Backblaze B2 ha guidato il GET a 5MiB con 399,49 MiB/s, mentre IDrive^® e2 ha guidato in 256KiB, 50MiB e 100MiB. Questi risultati misti mostrano perché è importante confrontare la categoria di carico di lavoro che corrisponde alla propria applicazione.

2.3 Throughput GET a 10 thread

Leader di categoria: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: IDrive^® e2.

Con dieci thread, IDrive^® e2 ha guidato tutte e quattro le categorie di dimensione GET, da 171,43 MiB/s a 256KiB fino a 1.034,81 MiB/s a 100MiB. Questo mostra che il suo vantaggio è aumentato con l'aumentare della concorrenza.

2.4 Scalabilità della concorrenza GET

Per gli oggetti da 256KiB, l'overhead di elaborazione delle richieste è il fattore principale. Per gli oggetti da 100MiB, la velocità di trasferimento sostenuta e il parallelismo contano di più. Questi due casi aiutano a interpretare i risultati completi. Le differenze più chiare a concorrenza più elevata sono particolarmente rilevanti per carichi di lavoro di ripristino, distribuzione dei contenuti e analisi con molte richieste di lettura attive.

3. Latenza delle richieste

La latenza è il tempo medio necessario per completare una richiesta, misurato da Warp. Una latenza più bassa significa risposte più rapide. È importante considerare sia il throughput sia la latenza, poiché un provider può avere un throughput complessivo elevato ma impiegare comunque più tempo per ogni richiesta.

I grafici della latenza mostrano ogni dimensione oggetto in un pannello separato, in modo che i valori più grandi di 50MiB e 100MiB non rendano difficili da leggere i risultati degli oggetti più piccoli. I nomi dei provider restano fissi sull'asse verticale e ogni barra è etichettata con il proprio valore. Questa impostazione aiuta a confrontare direttamente i risultati, senza dover dedurre dai colori o dalla lunghezza delle barre.

4. Coerenza

Il coefficiente di variazione, o CV, mostra quanto i risultati del benchmark siano cambiati da una run all'altra rispetto alla media. Un CV più basso significa che le prestazioni erano più stabili e prevedibili, mentre un CV più alto indica una maggiore variazione tra le run.

5. Interpretazione del carico di lavoro

5.1 Carichi di lavoro con oggetti piccoli

I test da 256KiB si concentrano su quanto bene i provider gestiscono le richieste, riutilizzano le connessioni, elaborano i metadati e gestiscono l'overhead API. Questi risultati sono più rilevanti per indici di backup, miniature, piccole risorse applicative e carichi di lavoro con molti oggetti piccoli.

5.2 Carichi di lavoro di dimensione media

I test da 5MiB e 50MiB rappresentano tipici file di backup, segmenti multimediali, bundle applicativi e file di analisi. I risultati mostrano quanto ciascun provider sia efficiente con upload singoli e quanto gli upload paralleli possano aumentare la velocità complessiva.

5.3 Carichi di lavoro con oggetti grandi

I test da 100MiB si concentrano maggiormente sul trasferimento sostenuto dei dati di rete e del servizio. I risultati con dieci thread sono utili per backup parallelo, ripristino, replica e spostamento dei dati, mentre i risultati a un thread mostrano cosa aspettarsi con trasferimenti singoli.

5.4 Interpretazione appropriata

Questi test si basano sui risultati di un singolo client nell'US East. Non coprono ogni regione, posizione del client, percorso di rete, ora del giorno, SDK o pattern applicativo. I lettori dovrebbero concentrarsi soprattutto sui casi di test che corrispondono alle proprie dimensioni degli oggetti e alla propria concorrenza.

6. Benchmark LIST, HEAD e DELETE di un giorno

LIST, HEAD e DELETE sono stati eseguiti come benchmark operativi separati di un giorno. A differenza delle sezioni PUT e GET, queste misurazioni non sono medie su sette cicli. Ogni test ha usato la stessa origine di test US East e 10 worker concorrenti. LIST e DELETE hanno usato un insieme preparato di 100.000 oggetti, mentre HEAD ha usato 50.000 oggetti come bersaglio delle richieste. LIST e HEAD sono durati circa cinque minuti. DELETE è continuato fino a quando il set fisso di oggetti è stato elaborato.

6.1 Configurazione del test

Per HEAD, "50,000 objects" rappresenta il set di oggetti disponibile per le richieste di metadati. Warp ha completato più richieste HEAD rispetto al numero di oggetti unici, perché il test basato sulla durata ha continuato a inviare richieste per tutta la sua esecuzione.

6.2 Prestazioni LIST

IDrive^® e2 ha avuto il throughput LIST medio più alto con 71.467,78 oggetti/s e la latenza media LIST più bassa con 1.409,9 ms. Il suo TTFB medio era di 14 ms. Questi numeri provengono da un solo giorno e non vanno considerati medie a lungo termine.

Le prestazioni LIST dipendono da paginazione, attraversamento delle chiavi, costruzione della risposta e capacità del client di elaborare ogni pagina. Il throughput (oggetti al secondo) mostra quanto rapidamente sono stati restituiti gli elementi oggetto, mentre la latenza media delle richieste è il tempo per ogni richiesta LIST. TTFB mostra quanto rapidamente sono arrivati i primi dati della risposta. Poiché il test era basato sulla durata, il grafico dell'intervallo mostra anche la variazione a breve termine durante l'esecuzione.

6.3 Prestazioni HEAD

IDrive^® e2 ha registrato il throughput HEAD medio più alto con 1.017,80 oggetti/s e la latenza media delle richieste più bassa con 9,8 ms. Backblaze B2 si è classificato al secondo posto con 770,76 oggetti/s, seguito da Wasabi con 691,42 oggetti/s, AWS S3 con 475,95 oggetti/s e Cloudflare R2 con 98,24 oggetti/s. Tutti e cinque i provider hanno completato il test senza errori segnalati.

6.4 Prestazioni DELETE

IDrive^® e2 ha ottenuto il throughput DELETE comparabile più alto con 3.475,88 oggetti/s e la latenza media delle richieste più bassa con 290,43 ms. Cloudflare R2 si è classificato al secondo posto con un throughput medio di 2.022,16 oggetti/s e una latenza di 495,89 ms, seguito da AWS S3 con 1.032,09 oggetti/s e Wasabi con 815,72 oggetti/s.

Nota: Backblaze B2 è stato escluso dal confronto DELETE perché i bucket B2 sono intrinsecamente versionati e non supportano una modalità convenzionale non versionata. Il benchmark DELETE standard di Warp invia richieste DELETE basate sul nome senza enumerare ed eliminare gli ID di versione individuali. Su B2, tali richieste creano delete marker anziché rimuovere permanentemente le versioni degli oggetti archiviati, rendendo i risultati non adatti a un confronto diretto con le operazioni DELETE non versionate.

6.5 Avvertenze per LIST/HEAD/DELETE

• Si tratta di un confronto di un solo giorno e non mostra la coerenza da un giorno all'altro.
• LIST e HEAD sono test basati sulla durata, mentre DELETE si conclude dopo che il set fisso di oggetti è stato elaborato. Il loro comportamento di throughput e completamento dovrebbe quindi essere interpretato separatamente.
• La paginazione lato provider, l'implementazione del listing, il batching delle delete, il throttling e la configurazione del bucket possono influire in modo significativo sui risultati.
• Questi valori sono una istantanea operativa dell'ambiente testato e sono separati dai risultati PUT/GET su sette cicli.

7. Metodologia e controlli di qualità

7.1 Benchmark PUT e GET su sette cicli

Il benchmark ha utilizzato Warp da una VM Vultr Linux nell'US East. Ogni provider ha ricevuto le stesse combinazioni di operazioni, dimensioni degli oggetti, concorrenza e durate. La matrice comprendeva 24 configurazioni di carico di lavoro per provider e per ciclo: due operazioni, quattro dimensioni di oggetto e tre livelli di thread. Ogni carico di lavoro è durato cinque minuti.

Ogni ciclo di test ha mantenuto le stesse dimensioni del carico di lavoro in modo che i risultati giornalieri potessero essere aggregati su base omogenea. PUT e GET sono stati valutati indipendentemente a 256KiB, 5MiB, 50MiB e 100MiB usando 1, 5 e 10 worker concorrenti. Ogni carico di lavoro è durato cinque minuti. Questo progetto produce osservazioni sia sequenziali sia parallele senza combinare dimensioni di oggetto o livelli di concorrenza fondamentalmente diversi in un unico punteggio.

7.2 Criteri per risultati validi

Un risultato a livello di run è stato incluso quando Warp ha prodotto un report finale completo contenente una misurazione del throughput numerica valida. Un codice di uscita del wrapper diverso da zero o un timeout del wrapper non invalidavano automaticamente il risultato quando Warp aveva già completato il benchmark e prodotto statistiche finali utilizzabili. Le run sono state escluse quando non era disponibile un risultato finale numerico completo, inclusi i fallimenti durante la preparazione del test, gli errori di servizio non disponibile e i timeout DNS o di rete che impedivano l'esecuzione del benchmark.

7.3 Aggregazione

Per ogni cella provider-workload, il report calcola la media aritmetica dei valori di throughput validi a livello di run. I numeri dei campioni variano laddove i risultati siano stati esclusi. I valori di latenza sono derivati dai risultati validi delle stesse celle di carico di lavoro.

Nessun risultato mancante viene convertito in zero, perché ciò mescolerebbe le prestazioni con il completamento del test e ridurrebbe artificialmente la media. I risultati esclusi rimangono invece visibili nel conteggio dei campioni e nella reportistica sulla disponibilità. Le matrici su sette cicli negli appendici mantengono la visualizzazione a livello di run, consentendo ai lettori di vedere le singole osservazioni dietro le tabelle e i grafici riassuntivi.

Sono state identificate nove run incomplete tra Wasabi e Backblaze B2. Tre test PUT di Wasabi hanno raggiunto il timeout di Warp, cinque test GET di Backblaze B2 sono falliti perché il servizio non era disponibile durante la preparazione del test e un test PUT di Backblaze B2 è fallito a causa di un timeout DNS/I/O.

7.4 Benchmark di un giorno per LIST,HEAD e DELETE

LIST, HEAD e DELETE hanno usato lo stesso set di provider, la stessa origine di test US East e lo stesso livello di concorrenza di 10 worker, ma i loro design di esecuzione erano diversi. LIST e HEAD erano test basati sulla durata che sono durati circa cinque minuti. DELETE ha elaborato un set fisso di oggetti ed è terminato quando quel set è stato completato. I loro risultati sono presentati in modo indipendente e non vengono combinati con le medie PUT e GET su sette cicli né usati per creare un punteggio complessivo del provider.

7.5 Unità

• Throughput PUT e GET: MiB/s.
• Throughput LIST, HEAD e DELETE: oggetti/s.
• Latenza delle richieste e TTFB: millisecondi.

7.6 Log completi del benchmark

Per garantire riproducibilità e revisione indipendente, i log completi delle esecuzioni Warp e gli artefatti di benchmark di supporto sono referenziati nel repository pubblico seguente:

Log completi del benchmark Warp: https://github.com/e2-idrive/s3-benchmark-logs

Il repository fornisce il materiale a livello di run usato per convalidare gli aggregati riportati, analizzare le run escluse o fallite e riprodurre i calcoli descritti in questo report.

8. Limitazioni

• Una singola posizione client e un singolo percorso di rete; i risultati possono differire tra regioni, ISP, cloud o reti aziendali.
• Carichi di lavoro sintetici: Warp offre ripetibilità ma non riproduce il mix di richieste, il comportamento dell'SDK, i retry o la distribuzione delle chiavi oggetto di ogni applicazione.
• Periodo di osservazione limitato: PUT e GET si estendono su sette cicli; LIST, HEAD e DELETE sono istantanee di un giorno.
• Nessuna analisi di costo, durabilità, funzionalità, supporto o egress: questo report è incentrato sulle prestazioni.
• Nessun confronto di latenza percentile su tutti i grafici: per leggibilità vengono mostrati i valori medi; le applicazioni sensibili alla tail latency dovrebbero eseguire test P95/P99 specifici per il carico di lavoro.
• Risultati esclusi: le medie si basano su campioni validi e possono avere conteggi di campione non uniformi tra provider e celle di carico di lavoro.

Cosa mostrano i risultati

In questo test US East, IDrive^® e2 ha guidato nei carichi PUT medi e in 9 su 12 carichi GET medi. Backblaze B2 ha guidato il GET a 1 thread a 5MiB e 50MiB, e il GET a 5 thread a 5MiB. I test operativi di un giorno sono separati da questi risultati su sette cicli.

Questo report non crea un punteggio unico per ciascun provider. Applicazioni diverse si interessano a cose diverse, come upload, download, listing, eliminazione, dimensione degli oggetti, concorrenza, latenza, coerenza, posizione e costo. Il modo migliore per usare questi risultati è scegliere l'operazione e il carico di lavoro che corrispondono alle proprie esigenze, quindi confrontare sia la media sia i dati dettagliati a livello di run.