Comparaison du stockage objet

1. Performances d'upload (PUT)

PUT mesure le débit d'upload soutenu en MiB/s. Les sections suivantes séparent le comportement séquentiel de la montée en charge concurrente et montrent les nombres d'échantillons valides ainsi que les moyennes.

1.1 Débit PUT à 1 thread

IDrive^® e2 a mené les quatre catégories de taille d'objet à 1 thread. Sa moyenne allait de 9,37 MiB/s à 256 KiB à 307,30 MiB/s à 100 MiB.

1.2 Débit PUT à 5 threads

IDrive^® e2 a mené les quatre catégories de taille d'objet à 5 threads. Sa moyenne allait de 47,71 MiB/s à 256KiB à 1.400,18 MiB/s à 100MiB.

Les tests à cinq threads représentent un niveau modéré de parallélisme côté client et peuvent être pertinents pour les applications de sauvegarde, de synchronisation et de migration qui utilisent plusieurs transferts simultanés.

Les classements observés avec un thread sont restés les mêmes à mesure que la concurrence augmentait. Cela signifie que le meilleur performer a géré davantage d'uploads simultanés sur toutes les tailles d'objets, et pas seulement des transferts uniques.

1.3 Débit PUT à 10 threads

IDrive^® e2 a mené les quatre catégories de taille d'objet à 10 threads. Sa moyenne allait de 93,00 MiB/s à 256 KiB à 1.879,48 MiB/s à 100 MiB.

Les résultats à dix threads constituent l'indication la plus forte de la capacité d'upload agrégée dans cette matrice de test. Le débit PUT pour les gros objets a augmenté de façon substantielle sur tous les fournisseurs, mais l'ampleur de la montée en charge variait. Ces valeurs sont les plus pertinentes pour les workflows parallèles de sauvegarde, de réplication, de migration et d'ingestion média qui maintiennent plusieurs uploads actifs au lieu d'attendre qu'un objet se termine avant d'envoyer le suivant.

1.4 Montée en charge de la concurrence PUT

Les courbes de montée en charge montrent si le débit augmente lorsque davantage de workers sont ajoutés, de un à 10. Les objets plus grands voient généralement des gains plus importants, car l'overhead de connexion et de requête pèse moins. Pour les petits objets, la montée en charge dépend surtout de l'overhead de traitement des requêtes, tandis que pour les objets de 100MiB, elle reflète la vitesse de transfert soutenue et la manière dont les flux concurrents sont utilisés.

2. Performances de download (GET)

GET mesure la quantité de données pouvant être téléchargée dans le temps, en MiB/s. Comparé à PUT, le GET à un seul thread est plus homogène entre les fournisseurs, mais les différences deviennent plus nettes lorsque davantage de threads sont utilisés.

2.1 Débit GET à 1 thread

Leader par catégorie : 256KiB : IDrive^® e2, 5MiB : Backblaze B2 ; 50MiB : Backblaze B2 ; 100MiB : IDrive^®e2.

Le GET à un thread était la partie la plus compétitive du test. Backblaze B2 a mené dans les catégories 5MiB et 50MiB, tandis qu'IDrive^® e2 a mené en 256KiB et 100MiB. Les résultats à 5MiB étaient serrés : Backblaze B2 a affiché une moyenne de 64,87 MiB/s, AWS S3 63,36 MiB/s et IDrive^® e2 63,13 MiB/s.

2.2 Débit GET à 5 threads

Leader par catégorie : 100MiB : IDrive^® e2, 256KiB : IDrive^® e2, 50MiB : IDrive^® e2, 5MiB : Backblaze B2.

Avec cinq threads, Backblaze B2 a mené le GET 5MiB avec 399,49 MiB/s, tandis qu'IDrive^® e2 a mené en 256KiB, 50MiB et 100MiB. Ces résultats mixtes montrent pourquoi il est important de comparer la catégorie de charge de travail qui correspond à votre application.

2.3 Débit GET à 10 threads

Leader par catégorie : 100MiB : IDrive^® e2, 256KiB : IDrive^® e2, 50MiB : IDrive^® e2, 5MiB : IDrive^® e2.

Avec dix threads, IDrive^® e2 a mené les quatre catégories de taille GET, de 171,43 MiB/s à 256KiB jusqu'à 1.034,81 MiB/s à 100MiB. Cela montre que son avantage s'est accru avec la concurrence.

2.4 Montée en charge de la concurrence GET

Pour les objets de 256KiB, l'overhead de traitement des requêtes est le facteur principal. Pour les objets de 100MiB, la vitesse de transfert soutenue et le parallélisme comptent davantage. Ces deux cas aident à interpréter l'ensemble des résultats. Les différences plus nettes à concurrence plus élevée sont particulièrement pertinentes pour les charges de travail de restauration, de diffusion de contenu et d'analyse avec de nombreuses requêtes de lecture actives.

3. Latence des requêtes

La latence est le temps moyen nécessaire pour terminer une requête, mesuré par Warp. Une latence plus faible signifie des réponses plus rapides. Il est important de considérer à la fois le débit et la latence, car un fournisseur peut avoir un débit global élevé tout en prenant plus de temps pour chaque requête.

Les graphiques de latence montrent chaque taille d'objet dans un panneau séparé, afin que les valeurs plus importantes de 50MiB et 100MiB ne rendent pas les résultats des petits objets difficiles à voir. Les noms des fournisseurs restent fixes sur l'axe vertical, et chaque barre est étiquetée avec sa valeur. Cette configuration aide à comparer directement les résultats, sans devoir deviner à partir des couleurs ou des longueurs de barres.

4. Cohérence

Le coefficient de variation, ou CV, montre combien les résultats du benchmark ont changé d'une exécution à l'autre par rapport à la moyenne. Un CV plus faible signifie que les performances étaient plus stables et plus prévisibles, tandis qu'un CV plus élevé indique davantage de variation entre les exécutions.

5. Interprétation de la charge de travail

5.1 Charges de travail à petits objets

Les tests 256KiB se concentrent sur la capacité des fournisseurs à gérer les requêtes, réutiliser les connexions, traiter les métadonnées et gérer l'overhead API. Ces résultats sont les plus pertinents pour les index de sauvegarde, les miniatures, les petites ressources d'application et les charges de travail comportant de nombreux petits objets.

5.2 Charges de travail de taille moyenne

Les tests 5MiB et 50MiB représentent des fichiers de sauvegarde typiques, des segments multimédias, des bundles d'application et des fichiers d'analyse. Les résultats montrent l'efficacité de chaque fournisseur pour les uploads uniques et dans quelle mesure les uploads parallèles peuvent accroître la vitesse globale.

5.3 Charges de travail à gros objets

Les tests 100MiB se concentrent davantage sur le transfert soutenu des données réseau et service. Les résultats à dix threads sont utiles pour la sauvegarde parallèle, la restauration, la réplication et les déplacements de données, tandis que les résultats à un thread montrent ce qu'il faut attendre des transferts uniques.

5.4 Interprétation appropriée

Ces tests sont basés sur les résultats d'un seul client dans US East. Ils ne couvrent pas chaque région, emplacement client, trajet réseau, heure de la journée, SDK ou modèle d'application. Les lecteurs devraient surtout se concentrer sur les cas de test qui correspondent à leurs propres tailles d'objets et à leur concurrence.

6. Benchmark LIST, HEAD et DELETE sur une journée

LIST, HEAD et DELETE ont été exécutés comme benchmarks opérationnels séparés sur une journée. Contrairement aux sections PUT et GET, ces mesures ne sont pas des moyennes sur sept cycles. Chaque test a utilisé la même origine de test US East et 10 workers concurrents. LIST et DELETE ont utilisé un ensemble préparé de 100.000 objets, tandis que HEAD a utilisé 50.000 objets comme cible des requêtes. LIST et HEAD ont duré environ cinq minutes. DELETE s'est poursuivi jusqu'à ce que l'ensemble fixe d'objets ait été traité.

6.1 Configuration du test

Pour HEAD, "50,000 objects" représente l'ensemble d'objets disponible pour les requêtes de métadonnées. Warp a effectué plus de requêtes HEAD que le nombre d'objets uniques, car le test basé sur la durée a continué à envoyer des requêtes pendant toute son exécution.

6.2 Performances LIST

IDrive^® e2 a obtenu le débit LIST moyen le plus élevé avec 71.467,78 objets/s et la latence moyenne LIST la plus faible avec 1.409,9 ms. Son TTFB moyen était de 14 ms. Ces chiffres proviennent d'une seule journée et ne doivent pas être considérés comme des moyennes à long terme.

Les performances LIST dépendent de la pagination, de la traversée des clés, de la construction de la réponse et de la capacité du client à traiter chaque page. Le débit (objets par seconde) montre la vitesse à laquelle les entrées objet ont été renvoyées, tandis que la latence moyenne des requêtes correspond au temps de chaque requête LIST. Le TTFB indique la rapidité d'arrivée des premières données de réponse. Comme le test était basé sur la durée, le graphique d'étendue montre aussi les variations à court terme pendant l'exécution.

6.3 Performances HEAD

IDrive^® e2 a enregistré le débit HEAD moyen le plus élevé avec 1.017,80 objets/s et la latence moyenne de requête la plus faible avec 9,8 ms. Backblaze B2 s'est classé deuxième à 770,76 objets/s, suivi de Wasabi à 691,42 objets/s, AWS S3 à 475,95 objets/s et Cloudflare R2 à 98,24 objets/s. Les cinq fournisseurs ont terminé le test sans erreur signalée.

6.4 Performances DELETE

IDrive^® e2 a obtenu le débit DELETE comparable le plus élevé avec 3.475,88 objets/s et la latence moyenne de requête la plus faible avec 290,43 ms. Cloudflare R2 s'est classé deuxième avec un débit moyen de 2.022,16 objets/s et une latence de 495,89 ms, suivi d'AWS S3 avec 1.032,09 objets/s et de Wasabi avec 815,72 objets/s.

Note : Backblaze B2 a été exclu de la comparaison DELETE car les buckets B2 sont intrinsèquement versionnés et ne prennent pas en charge un mode classique non versionné. Le benchmark DELETE standard de Warp envoie des requêtes DELETE basées sur le nom sans énumérer ni supprimer les ID de version individuels. Sur B2, de telles requêtes créent des marqueurs de suppression au lieu de supprimer définitivement les versions d'objets stockées, ce qui rend ses résultats inadaptés à une comparaison directe avec les opérations DELETE non versionnées.

6.5 Avertissements LIST/HEAD/DELETE

• Il s'agit d'une comparaison d'une journée et elle ne montre pas la cohérence d'un jour à l'autre.
• LIST et HEAD sont des tests basés sur la durée, tandis que DELETE se termine après le traitement de l'ensemble fixe d'objets. Leur débit et leur comportement d'achèvement doivent donc être interprétés séparément.
• La pagination côté fournisseur, l'implémentation de la liste, le batching des suppressions, la limitation et la configuration du bucket peuvent affecter sensiblement les résultats.
• Ces chiffres constituent une vue opérationnelle de la configuration testée et sont distincts des résultats PUT/GET sur sept cycles.

7. Méthodologie et contrôles qualité

7.1 Benchmark PUT et GET sur sept cycles

Le benchmark a utilisé Warp depuis une VM Vultr Linux en US East. Chaque fournisseur a reçu les mêmes combinaisons d'opérations, de tailles d'objets, de concurrence et de durées. La matrice comprenait 24 configurations de charge de travail par fournisseur et par cycle : deux opérations, quatre tailles d'objet et trois niveaux de threads. Chaque charge de travail s'exécutait pendant cinq minutes.

Chaque cycle de test conservait les mêmes dimensions de charge afin que les résultats quotidiens puissent être agrégés sur une base comparable. PUT et GET ont été évalués indépendamment à 256KiB, 5MiB, 50MiB et 100MiB en utilisant 1, 5 et 10 workers concurrents. Chaque charge de travail s'exécutait pendant cinq minutes. Cette conception produit des observations séquentielles et parallèles sans combiner des tailles d'objets ou des niveaux de concurrence fondamentalement différents en une seule note.

7.2 Critères de résultat valide

Un résultat au niveau du run était inclus lorsque Warp produisait un rapport final complet contenant une mesure de débit numérique valide. Un code de sortie du wrapper non nul ou un timeout du wrapper n'invalidait pas automatiquement le résultat lorsque Warp avait déjà terminé le benchmark et produit des statistiques finales exploitables. Les runs étaient exclus lorsqu'aucun résultat final numérique complet n'était disponible, y compris les échecs pendant la préparation du test, les erreurs de service indisponible et les timeouts DNS ou réseau empêchant l'exécution du benchmark.

7.3 Agrégation

Pour chaque cellule fournisseur-charge de travail, le rapport calcule la moyenne arithmétique des valeurs de débit valides au niveau du run. Les tailles d'échantillon varient lorsque des résultats ont été exclus. Les chiffres de latence sont dérivés des résultats valides pour les mêmes cellules de charge.

Aucun résultat manquant n'est converti en zéro, car cela mélangerait performance et achèvement du test et réduirait artificiellement la moyenne. Les résultats exclus restent au contraire visibles dans le nombre d'échantillons et dans le rapport de disponibilité. Les matrices sur sept cycles dans les annexes conservent la vue au niveau du run, permettant aux lecteurs de voir les observations individuelles derrière les tableaux et graphiques récapitulatifs.

Neuf runs incomplètes ont été identifiées chez Wasabi et Backblaze B2. Trois tests PUT Wasabi ont atteint le timeout Warp, cinq tests GET Backblaze B2 ont échoué car le service était indisponible pendant la préparation du test, et un test PUT Backblaze B2 a échoué en raison d'un timeout de résolution DNS/I/O.

7.4 Benchmark d'une journée LIST,HEAD et DELETE

LIST, HEAD et DELETE ont utilisé le même ensemble de fournisseurs, la même origine de test US East et le même niveau de concurrence de 10 workers, mais leurs conceptions d'exécution différaient. LIST et HEAD étaient des tests basés sur la durée qui ont duré environ cinq minutes. DELETE a traité un ensemble fixe d'objets et s'est terminé lorsque cet ensemble avait été complété. Leurs résultats sont présentés indépendamment et ne sont pas combinés avec les moyennes PUT et GET sur sept cycles ni utilisés pour créer un score global de fournisseur.

7.5 Unités

• Débit PUT et GET : MiB/s.
• Débit LIST, HEAD et DELETE : objets/s.
• Latence des requêtes et TTFB : millisecondes.

7.6 Journaux complets du benchmark

Pour la reproductibilité et l'examen indépendant, les journaux complets des exécutions Warp et les artefacts de benchmark associés sont référencés dans le dépôt public ci-dessous :

Journaux complets du benchmark Warp : https://github.com/e2-idrive/s3-benchmark-logs

Le dépôt fournit le matériel au niveau du run utilisé pour valider les agrégats rapportés, examiner les runs exclues ou échouées, et reproduire les calculs décrits dans ce rapport.

8. Limites

• Emplacement client unique et trajet réseau unique ; les résultats peuvent différer selon les régions, les FAI, les clouds ou les réseaux d'entreprise.
• Charges de travail synthétiques : Warp offre de la répétabilité mais ne reproduit pas le mix de requêtes, le comportement SDK, les retries ou la distribution des clés d'objet de chaque application.
• Période d'observation limitée : PUT et GET couvrent sept cycles ; LIST, HEAD et DELETE sont des instantanés d'une journée.
• Aucune analyse de coût, de durabilité, de fonctionnalités, de support ou d'egress : ce rapport est axé sur les performances.
• Aucune comparaison des latences en percentile sur tous les graphiques : les moyennes sont affichées pour la lisibilité ; les applications sensibles à la tail latency devraient effectuer des tests P95/P99 spécifiques à la charge de travail.
• Résultats exclus : les moyennes sont basées sur des échantillons valides et peuvent présenter des tailles d'échantillons inégales selon les fournisseurs et les cellules de charge.

Ce que montrent les résultats

Dans ce test US East, IDrive^® e2 a mené dans les charges PUT moyennes et dans 9 sur 12 charges GET moyennes. Backblaze B2 a mené le GET à 1 thread à 5MiB et 50MiB, ainsi que le GET à 5 threads à 5MiB. Les tests opérationnels d'une journée sont distincts de ces résultats sur sept cycles.

Ce rapport ne crée pas de score unique pour chaque fournisseur. Les applications diffèrent sur les points qui comptent, comme l'upload, le download, le listing, la suppression, la taille des objets, la concurrence, la latence, la cohérence, la localisation et le coût. La meilleure façon d'utiliser ces résultats est de choisir l'opération et la charge de travail qui correspondent à vos besoins, puis de comparer à la fois la moyenne et les données détaillées au niveau du run.