Comparación de Object Storage

1. Rendimiento de upload (PUT)

PUT mide el throughput sostenido de upload en MiB/s. Las siguientes secciones separan el comportamiento secuencial del escalado concurrente y muestran recuentos válidos de muestras junto con promedios.

1.1 Throughput PUT de 1 thread

IDrive^® e2 lideró las cuatro categorías de tamaño de object a 1 thread. Su promedio osciló entre 9,37 MiB/s en 256 KiB y 307,30 MiB/s en 100 MiB.

1.2 Throughput PUT de 5 threads

IDrive^® e2 lideró las cuatro categorías de tamaño de object a 5 threads. Su promedio osciló entre 47,71 MiB/s en 256KiB y 1.400,18 MiB/s en 100MiB.

Las pruebas de cinco threads representan un nivel moderado de paralelismo del lado del client y pueden ser relevantes para aplicaciones de backup, sincronización y migración que usan varios transfers simultáneos.

Los rankings vistos con un thread se mantuvieron iguales a medida que aumentó la concurrency. Esto significa que el mejor rendimiento gestionó más uploads simultáneos en todos los tamaños de object, no solo transfers individuales.

1.3 Throughput PUT de 10 threads

IDrive^® e2 lideró las cuatro categorías de tamaño de object a 10 threads. Su promedio osciló entre 93,00 MiB/s en 256KiB y 1.879,48 MiB/s en 100MiB.

Los resultados de diez threads son la indicación más fuerte de la capacidad agregada de upload en esta matriz de prueba. El PUT throughput para objects grandes aumentó de forma sustancial en todos los proveedores, pero el grado de escalado varió. Estos valores son más relevantes para flujos de trabajo paralelos de backup, replicación, migración e ingestión de media que mantienen varios uploads activos en lugar de esperar a que un object termine antes de enviar el siguiente.

1.4 Escalado de concurrency PUT

Las curvas de escalado muestran si el throughput aumenta a medida que se añaden más workers, de uno a 10. Los objects más grandes suelen ver mayores ganancias porque el overhead de conexión y request pesa menos. En objects pequeños, el escalado depende sobre todo del overhead de procesamiento de request, mientras que en objects de 100MiB refleja la velocidad de transferencia sostenida y qué tan bien se usan los streams concurrentes.

2. Rendimiento de download (GET)

GET mide cuántos datos pueden descargarse con el tiempo, en MiB/s. En comparación con PUT, el GET de un solo thread es más parecido entre proveedores, pero las diferencias se vuelven más claras cuando se usan más threads.

2.1 Throughput GET de 1 thread

Líderes por categoría: 256KiB: IDrive^® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive^®e2.

El GET de un solo thread fue la parte más competitiva de la prueba. Backblaze B2 lideró en las categorías 5MiB y 50MiB, mientras que IDrive^® e2 lideró en 256KiB y 100MiB. Los resultados de 5MiB estuvieron muy ajustados: Backblaze B2 promedió 64,87 MiB/s, AWS S3 63,36 MiB/s e IDrive^® e2 63,13 MiB/s.

2.2 Throughput GET de 5 threads

Líderes por categoría: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: Backblaze B2.

Con cinco threads, Backblaze B2 lideró el GET de 5MiB con 399,49 MiB/s, mientras que IDrive^® e2 lideró en 256KiB, 50MiB y 100MiB. Estos resultados mixtos muestran por qué es importante comparar la categoría de workload que coincide con su aplicación.

2.3 Throughput GET de 10 threads

Líderes por categoría: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: IDrive^® e2.

Con diez threads, IDrive^® e2 lideró las cuatro categorías de tamaño GET, desde 171,43 MiB/s en 256KiB hasta 1.034,81 MiB/s en 100MiB. Esto muestra que su ventaja creció a medida que aumentó la concurrency.

2.4 Escalado de concurrency GET

Para objects de 256KiB, el overhead de procesamiento de requests es el factor principal. Para objects de 100MiB, la velocidad sostenida de transferencia y el paralelismo importan más. Estos dos casos ayudan a interpretar los resultados completos. Las diferencias más claras con mayor concurrency son especialmente relevantes para cargas de trabajo de restore, entrega de contenido y análisis con muchos requests de lectura activos.

3. Latencia de request

La latencia es el tiempo medio que se tarda en completar un request, medido por Warp. Una latencia menor significa respuestas más rápidas. Es importante mirar tanto el throughput como la latencia, ya que un proveedor puede tener un throughput total alto pero aun así tardar más en cada request.

Los charts de latencia muestran cada tamaño de object en un panel separado, de modo que los valores más grandes de 50MiB y 100MiB no dificulten ver los resultados de objects más pequeños. Los nombres de los proveedores permanecen fijos en el eje vertical y cada barra está etiquetada con su valor. Esta configuración ayuda a comparar directamente los resultados, sin adivinar por colores o longitudes de barra.

4. Consistencia

El coeficiente de variación, o CV, muestra cuánto cambiaron los resultados del benchmark de una ejecución a otra en comparación con el promedio. Un CV más bajo significa que el rendimiento fue más estable y predecible, mientras que un CV más alto indica mayor variación entre ejecuciones.

5. Interpretación de workload

5.1 Workloads de objects pequeños

Las pruebas de 256KiB se centran en qué tan bien los proveedores manejan requests, reutilizan conexiones, procesan metadata y gestionan el overhead de API. Estos resultados son más relevantes para índices de backup, thumbnails, pequeños assets de apps y workloads con muchos objects pequeños.

5.2 Workloads de tamaño medio

Las pruebas de 5MiB y 50MiB representan archivos de backup típicos, segmentos de media, bundles de apps y archivos de análisis. Los resultados muestran qué tan eficiente es cada proveedor con uploads individuales y cuánto pueden aumentar la velocidad total los uploads paralelos.

5.3 Workloads de objects grandes

Las pruebas de 100MiB se centran más en la transferencia sostenida de datos de red y servicio. Los resultados con diez threads son útiles para backup paralelo, restore, replicación y movimiento de datos, mientras que los resultados con un thread muestran qué esperar con transfers individuales.

5.4 Interpretación adecuada

Estas pruebas se basan en resultados de un solo client en US East. No cubren todas las regiones, ubicaciones de client, rutas de red, horas del día, SDK o patrones de app. Los lectores deberían centrarse sobre todo en los casos de prueba que coincidan con sus propios tamaños de object y su concurrency.

6. Benchmark de un día para LIST, HEAD y DELETE

LIST, HEAD y DELETE se ejecutaron como benchmarks operativos separados de un día. A diferencia de las secciones PUT y GET, estas cifras no son promedios de siete ciclos. Cada prueba usó la misma fuente de prueba US East y 10 workers concurrentes. LIST y DELETE usaron un conjunto preparado de 100.000 objects, mientras que HEAD usó 50.000 objects como objetivo del request. LIST y HEAD se ejecutaron durante aproximadamente cinco minutos. DELETE continuó hasta que se procesó el conjunto fijo de objects.

6.1 Configuración de prueba

Para HEAD, "50,000 objects" representa el conjunto de objects disponible para requests de metadata. Warp completó más requests HEAD que el número de objects únicos porque la prueba basada en duración continuó enviando requests durante toda la ejecución.

6.2 Rendimiento LIST

IDrive^® e2 tuvo el mayor throughput LIST medio con 71,467.78 objects/s y la menor latencia media LIST con 1,409.9 ms. Su TTFB medio fue de 14 ms. Estos números son de un solo día y no deben tomarse como promedios a largo plazo.

El rendimiento LIST depende de la paginación, el recorrido de keys, la construcción de la respuesta y la capacidad del client para procesar cada página. El throughput (objects por segundo) muestra qué tan rápido se devolvieron las entradas de object, mientras que la latencia media de request es el tiempo de cada request LIST. TTFB muestra qué tan rápido llegaron los primeros datos de la respuesta. Como la prueba fue basada en duración, el chart de rango también muestra variación a corto plazo durante la ejecución.

6.3 Rendimiento HEAD

IDrive^® e2 registró el mayor throughput medio de HEAD con 1,017.80 objects/s y la menor latencia media de request con 9,8 ms. Backblaze B2 quedó en segundo lugar con 770.76 objects/s, seguido de Wasabi con 691.42 objects/s, AWS S3 con 475.95 objects/s y Cloudflare R2 con 98.24 objects/s. Los cinco proveedores completaron la prueba sin errores reportados.

6.4 Rendimiento DELETE

IDrive^® e2 logró el mayor throughput DELETE comparable con 3,475.88 objects/s y la menor latencia media de request con 290,43 ms. Cloudflare R2 quedó en segundo lugar con un throughput medio de 2,022.16 objects/s y una latencia de 495,89 ms, seguido de AWS S3 con 1,032.09 objects/s y Wasabi con 815.72 objects/s.

Nota: Backblaze B2 se excluyó de la comparación DELETE porque los buckets B2 están inherentemente versioned y no admiten un modo convencional no versionado. El benchmark DELETE estándar de Warp envía requests DELETE basados en nombres sin enumerar ni eliminar IDs de versión individuales. En B2, esos requests crean delete markers en lugar de eliminar permanentemente las versiones de object almacenadas, lo que hace que sus resultados no sean adecuados para una comparación directa con operaciones DELETE no versionadas.

6.5 Advertencias de LIST/HEAD/DELETE

• Esta es una comparación de un solo día y no muestra consistencia día a día.
• LIST y HEAD son pruebas basadas en duración, mientras que DELETE se completa después de que se procesa el conjunto fijo de objects. Por lo tanto, su comportamiento de throughput y finalización debe interpretarse por separado.
• La paginación del lado del proveedor, la implementación de listing, el batching de delete, el throttling y la configuración del bucket pueden afectar materialmente los resultados.
• Estas cifras son una instantánea operativa de la configuración probada y son separadas de los resultados PUT/GET de siete ciclos.

7. Metodología y controles de calidad

7.1 Benchmark PUT y GET de siete ciclos

El benchmark utilizó Warp desde una VM Vultr Linux en US East. Cada proveedor recibió las mismas combinaciones de operaciones, tamaños de object, concurrency y duraciones. La matriz comprendió 24 configuraciones de workload por proveedor y por ciclo: dos operaciones, cuatro tamaños de object y tres niveles de thread. Cada workload se ejecutó durante cinco minutos.

Cada ciclo de prueba conservó las mismas dimensiones de workload para que los resultados día a día pudieran agregarse sobre una base comparable. PUT y GET se evaluaron de forma independiente en 256KiB, 5MiB, 50MiB y 100MiB usando 1, 5 y 10 workers concurrentes. Cada workload se ejecutó durante cinco minutos. Este diseño produce observaciones secuenciales y paralelas sin combinar tamaños de object o niveles de concurrency fundamentalmente diferentes en una sola puntuación.

7.2 Criterios de resultado válido

Un resultado a nivel de ejecución se incluyó cuando Warp produjo un informe final completo que contenía una medición numérica válida de throughput. Un código de salida del wrapper distinto de cero o un timeout del wrapper no invalidó automáticamente el resultado cuando Warp ya había completado el benchmark y producido estadísticas finales utilizables. Las ejecuciones se excluyeron cuando no había un resultado final numérico completo, incluidos fallos durante la preparación de la prueba, errores de servicio no disponible y timeouts de DNS o red que impidieron ejecutar el benchmark.

7.3 Agregación

Para cada celda proveedor-workload, el informe calcula la media aritmética de los valores válidos de throughput a nivel de ejecución. Los recuentos de muestra varían cuando se excluyen resultados. Los valores de latencia se derivan de los resultados válidos de las mismas celdas de workload.

Ningún resultado faltante se convierte en cero, porque eso mezclaría rendimiento con finalización de la prueba y reduciría artificialmente el promedio. En cambio, los resultados excluidos permanecen visibles en el recuento de muestras y en el informe de disponibilidad. Las matrices de siete ciclos en los apéndices conservan la vista a nivel de ejecución, permitiendo a los lectores ver las observaciones individuales detrás de las tablas y charts resumidos.

Se identificaron nueve ejecuciones incompletas entre Wasabi y Backblaze B2. Tres pruebas PUT de Wasabi alcanzaron el timeout de Warp, cinco pruebas GET de Backblaze B2 fallaron porque el servicio no estaba disponible durante la preparación de la prueba, y una prueba PUT de Backblaze B2 falló por un timeout de DNS/I/O.

7.4 Benchmark de un día para LIST,HEAD y DELETE

LIST, HEAD y DELETE usaron el mismo conjunto de proveedores, la misma fuente de prueba US East y el mismo nivel de concurrency de 10 workers, pero sus diseños de ejecución diferían. LIST y HEAD fueron pruebas basadas en duración que se ejecutaron durante aproximadamente cinco minutos. DELETE procesó un conjunto fijo de objects y terminó cuando ese conjunto se completó. Sus resultados se presentan de forma independiente y no se combinan con los promedios PUT y GET de siete ciclos ni se usan para crear una puntuación general del proveedor.

7.5 Unidades

• Throughput PUT y GET: MiB/s.
• Throughput LIST, HEAD y DELETE: objects/s.
• Latencia de request y TTFB: milisegundos.

7.6 Logs completos del benchmark

Para reproducibilidad y revisión independiente, los logs completos de las ejecuciones de Warp y los artefactos de benchmark de apoyo se referencian en el repositorio público siguiente:

Logs completos del benchmark Warp: https://github.com/e2-idrive/s3-benchmark-logs

El repositorio proporciona el material a nivel de ejecución usado para validar los agregados reportados, investigar ejecuciones excluidas o fallidas, y reproducir los cálculos descritos en este informe.

8. Limitaciones

• Una sola ubicación de client y una sola ruta de red; los resultados pueden diferir entre regiones, ISP, clouds o redes empresariales.
• Workloads sintéticos: Warp ofrece repetibilidad pero no reproduce la mezcla de requests, el comportamiento del SDK, los retries o la distribución de object keys de cada aplicación.
• Periodo de observación limitado: PUT y GET abarcan siete ciclos; LIST, HEAD y DELETE son instantáneas de un día.
• Sin análisis de costo, durabilidad, funciones, soporte o egress: este informe está centrado en el rendimiento.
• Sin comparación de latencia por percentil en todos los charts: se muestran promedios para facilitar la lectura; las aplicaciones sensibles a tail latency deberían realizar pruebas P95/P99 específicas del workload.
• Resultados excluidos: los promedios se basan en muestras válidas y pueden tener recuentos de muestra desiguales entre proveedores y celdas de workload.

Qué muestran los resultados

En esta prueba US East, IDrive^® e2 lideró en las cargas PUT medias y en 9 de las 12 cargas GET medias. Backblaze B2 lideró el GET de 1 thread en 5MiB y 50MiB, y el GET de 5 threads en 5MiB. Las pruebas operativas de un día son separadas de estos resultados de siete ciclos.

Este informe no crea una única puntuación para cada proveedor. Distintas aplicaciones se fijan en cosas distintas, como upload, download, listing, eliminación, tamaño de object, concurrency, latencia, consistencia, ubicación y costo. La mejor manera de usar estos resultados es elegir la operación y el workload que se ajusten a sus necesidades, y luego comparar tanto el promedio como los datos detallados a nivel de ejecución.