Comparação de armazenamento de objetos

1. Desempenho de upload (PUT)

PUT mede o throughput sustentado de upload em MiB/s. As seções a seguir separam o comportamento sequencial da escala concorrente e mostram contagens válidas de amostras junto com as médias.

1.1 Throughput PUT com 1 thread

O IDrive^® e2 liderou todas as quatro categorias de tamanho de objeto com 1 thread. Sua média variou de 9,37 MiB/s em 256 KiB a 307,30 MiB/s em 100 MiB.

1.2 Throughput PUT com 5 threads

O IDrive^® e2 liderou todas as quatro categorias de tamanho de objeto com 5 threads. Sua média variou de 47,71 MiB/s em 256KiB a 1.400,18 MiB/s em 100MiB.

Os testes com cinco threads representam um nível moderado de paralelismo no lado do cliente e podem ser relevantes para aplicativos de backup, sincronização e migração que usam vários transfers simultâneos.

Os rankings vistos com uma thread permaneceram os mesmos à medida que a concorrência aumentou. Isso significa que o melhor desempenho lidou com mais uploads simultâneos em todos os tamanhos de objeto, não apenas transfers únicos.

1.3 Throughput PUT com 10 threads

O IDrive^® e2 liderou todas as quatro categorias de tamanho de objeto com 10 threads. Sua média variou de 93,00 MiB/s em 256 KiB a 1.879,48 MiB/s em 100 MiB.

Os resultados com dez threads são a indicação mais forte da capacidade agregada de upload nesta matriz de teste. O throughput PUT para objetos grandes cresceu substancialmente em todos os provedores, mas a extensão da escala variou. Esses valores são mais relevantes para fluxos de trabalho paralelos de backup, replicação, migração e ingestão de mídia que mantêm vários uploads ativos em vez de esperar que um objeto termine antes de enviar o próximo.

1.4 Escalonamento da concorrência PUT

As curvas de escala mostram se o throughput sobe à medida que mais workers são adicionados, de um a 10. Objetos maiores normalmente veem ganhos maiores porque o overhead de conexão e requisição pesa menos. Para objetos pequenos, a escala depende principalmente do overhead de processamento da requisição, enquanto para objetos de 100MiB ela reflete velocidade sustentada de transferência e quão bem os fluxos concorrentes são usados.

2. Desempenho de download (GET)

GET mede quanta informação pode ser baixada ao longo do tempo, em MiB/s. Em comparação com PUT, o GET com um thread é mais parecido entre os provedores, mas as diferenças ficam mais claras quando mais threads são usados.

2.1 Throughput GET com 1 thread

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

O GET com uma thread foi a parte mais competitiva do teste. O Backblaze B2 liderou nas categorias 5MiB e 50MiB, enquanto o IDrive^® e2 liderou em 256KiB e 100MiB. Os resultados de 5MiB foram próximos: o Backblaze B2 teve média de 64,87 MiB/s, o AWS S3 63,36 MiB/s e o IDrive^® e2 63,13 MiB/s.

2.2 Throughput GET com 5 threads

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

Com cinco threads, o Backblaze B2 liderou o GET de 5MiB com 399,49 MiB/s, enquanto o IDrive^® e2 liderou em 256KiB, 50MiB e 100MiB. Esses resultados mistos mostram por que é importante comparar a categoria de carga de trabalho que corresponde à sua aplicação.

2.3 Throughput GET com 10 threads

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

Com dez threads, o IDrive^® e2 liderou todas as quatro categorias de tamanho GET, de 171,43 MiB/s em 256KiB até 1.034,81 MiB/s em 100MiB. Isso mostra que sua vantagem cresceu à medida que a concorrência aumentou.

2.4 Escalonamento da concorrência GET

Para objetos de 256KiB, o overhead de processamento da requisição é o fator principal. Para objetos de 100MiB, a velocidade sustentada de transferência e o paralelismo importam mais. Esses dois casos ajudam a interpretar os resultados completos. As diferenças mais claras em maior concorrência são especialmente relevantes para cargas de trabalho de restauração, entrega de conteúdo e análise com muitas requisições de leitura ativas.

3. Latência de requisição

Latência é o tempo médio para concluir uma requisição, medido pelo Warp. Uma latência menor significa respostas mais rápidas. É importante olhar tanto para throughput quanto para latência, já que um provedor pode ter throughput total alto, mas ainda levar mais tempo por requisição.

Os gráficos de latência mostram cada tamanho de objeto em um painel separado, para que os valores maiores de 50MiB e 100MiB não tornem os resultados de objetos menores difíceis de ver. Os nomes dos provedores ficam fixos no eixo vertical, e cada barra é rotulada com seu valor. Essa configuração ajuda a comparar os resultados diretamente, sem adivinhar pelas cores ou pelo comprimento das barras.

4. Consistência

O coeficiente de variação, ou CV, mostra quanto os resultados do benchmark mudaram de uma execução para outra em comparação com a média. Um CV menor significa que o desempenho foi mais estável e previsível, enquanto um CV maior indica mais variação entre execuções.

5. Interpretação da carga de trabalho

5.1 Cargas com objetos pequenos

Os testes de 256KiB se concentram em quão bem os provedores lidam com requisições, reutilizam conexões, processam metadados e gerenciam overhead de API. Esses resultados são mais relevantes para índices de backup, miniaturas, pequenos ativos de aplicativos e cargas de trabalho com muitos objetos pequenos.

5.2 Cargas de tamanho médio

Os testes de 5MiB e 50MiB representam arquivos de backup típicos, segmentos de mídia, pacotes de aplicativos e arquivos de análise. Os resultados mostram quão eficiente cada provedor é com uploads únicos e quanto uploads paralelos podem aumentar a velocidade geral.

5.3 Cargas com objetos grandes

Os testes de 100MiB se concentram mais em transferência sustentada de dados de rede e do serviço. Os resultados com dez threads são úteis para backup paralelo, restauração, replicação e movimentação de dados, enquanto os resultados com uma thread mostram o que esperar de transfers únicos.

5.4 Interpretação adequada

Esses testes são baseados em resultados de um único cliente em US East. Eles não cobrem todas as regiões, locais de cliente, rotas de rede, horários do dia, SDKs ou padrões de aplicativo. Os leitores devem se concentrar principalmente nos casos de teste que correspondem aos seus próprios tamanhos de objeto e à sua concorrência.

6. Benchmark de um dia para LIST, HEAD e DELETE

LIST, HEAD e DELETE foram executados como benchmarks operacionais separados de um dia. Diferentemente das seções PUT e GET, esses números não são médias de sete ciclos. Cada teste usou a mesma origem de teste em US East e 10 workers concorrentes. LIST e DELETE usaram um conjunto preparado de 100.000 objetos, enquanto HEAD usou 50.000 objetos como alvo da requisição. LIST e HEAD rodaram por aproximadamente cinco minutos. DELETE continuou até que o conjunto fixo de objetos fosse processado.

6.1 Configuração do teste

Para HEAD, "50,000 objects" representa o conjunto de objetos disponível para requisições de metadados. O Warp completou mais requisições HEAD do que o número de objetos únicos porque o teste baseado em duração continuou enviando requisições durante toda a execução.

6.2 Desempenho LIST

O IDrive^® e2 teve o maior throughput LIST médio com 71.467,78 objetos/s e a menor latência média LIST com 1.409,9 ms. Seu TTFB médio foi de 14 ms. Esses números são de um único dia e não devem ser tratados como médias de longo prazo.

O desempenho LIST depende de paginação, travessia de chaves, construção da resposta e da capacidade do cliente de processar cada página. O throughput (objetos por segundo) mostra quão rapidamente as entradas de objeto foram retornadas, enquanto a latência média de requisição é o tempo de cada requisição LIST. O TTFB mostra quão rápido chegaram os primeiros dados da resposta. Como o teste foi baseado em duração, o gráfico de intervalo também mostra variação de curto prazo durante a execução.

6.3 Desempenho HEAD

O IDrive^® e2 registrou o maior throughput médio de HEAD, com 1.017,80 objetos/s, e a menor latência média de requisição, com 9,8 ms. O Backblaze B2 ficou em segundo com 770,76 objetos/s, seguido por Wasabi com 691,42 objetos/s, AWS S3 com 475,95 objetos/s e Cloudflare R2 com 98,24 objetos/s. Todos os cinco provedores concluíram o teste sem erros reportados.

6.4 Desempenho DELETE

O IDrive^® e2 alcançou o maior throughput DELETE comparável, com 3.475,88 objetos/s, e a menor latência média de requisição, com 290,43 ms. O Cloudflare R2 ficou em segundo lugar com throughput médio de 2.022,16 objetos/s e latência de 495,89 ms, seguido por AWS S3 com 1.032,09 objetos/s e Wasabi com 815,72 objetos/s.

Nota: O Backblaze B2 foi excluído da comparação DELETE porque buckets B2 são inerentemente versionados e não suportam um modo convencional sem versionamento. O benchmark DELETE padrão do Warp envia requisições DELETE baseadas em nome sem enumerar e excluir IDs de versão individuais. No B2, essas requisições criam delete markers em vez de remover permanentemente as versões de objetos armazenadas, tornando seus resultados inadequados para uma comparação direta com operações DELETE sem versionamento.

6.5 Observações sobre LIST/HEAD/DELETE

• Esta é uma comparação de um dia e não mostra consistência de um dia para o outro.
• LIST e HEAD são testes baseados em duração, enquanto DELETE é concluído após o conjunto fixo de objetos ter sido processado. Portanto, o comportamento de throughput e de conclusão deve ser interpretado separadamente.
• Paginação no lado do provedor, implementação da listagem, batching de exclusões, throttling e configuração do bucket podem afetar materialmente os resultados.
• Esses números são um instantâneo operacional da configuração testada e são separados dos resultados PUT/GET de sete ciclos.

7. Metodologia e controles de qualidade

7.1 Benchmark PUT e GET de sete ciclos

O benchmark usou Warp a partir de uma VM Vultr Linux em US East. Cada provedor recebeu as mesmas combinações de operações, tamanhos de objeto, concorrência e durações. A matriz compreendeu 24 configurações de carga de trabalho por provedor por ciclo: duas operações, quatro tamanhos de objeto e três níveis de thread. Cada carga de trabalho rodou por cinco minutos.

Cada ciclo de teste preservou as mesmas dimensões de carga de trabalho para que os resultados diários pudessem ser agregados em base equivalente. PUT e GET foram avaliados independentemente em 256KiB, 5MiB, 50MiB e 100MiB usando 1, 5 e 10 workers concorrentes. Cada carga de trabalho rodou por cinco minutos. Esse desenho produz observações sequenciais e paralelas sem combinar tamanhos de objeto ou níveis de concorrência fundamentalmente diferentes em uma única pontuação.

7.2 Critérios de resultado válido

Um resultado em nível de execução foi incluído quando o Warp produziu um relatório final completo contendo uma medição numérica válida de throughput. Um código de saída diferente de zero do wrapper ou um timeout do wrapper não invalidava automaticamente o resultado quando o Warp já havia concluído o benchmark e produzido estatísticas finais utilizáveis. As execuções foram excluídas quando não havia um resultado final numérico completo, incluindo falhas durante a preparação do teste, erros de serviço indisponível e timeouts de DNS ou de rede que impediram a execução do benchmark.

7.3 Agregação

Para cada célula provedor-carga de trabalho, o relatório calcula a média aritmética dos valores válidos de throughput em nível de execução. As contagens de amostra variam quando resultados foram excluídos. Os valores de latência são derivados dos resultados válidos das mesmas células de carga de trabalho.

Nenhum resultado ausente é convertido em zero, porque isso misturaria desempenho com conclusão do teste e reduziria artificialmente a média. Em vez disso, os resultados excluídos permanecem visíveis na contagem de amostras e na apresentação de disponibilidade. As matrizes de sete ciclos nos apêndices preservam a visão em nível de execução, permitindo que os leitores vejam as observações individuais por trás das tabelas e gráficos resumidos.

Nove execuções incompletas foram identificadas entre Wasabi e Backblaze B2. Três testes PUT do Wasabi atingiram o timeout do Warp, cinco testes GET do Backblaze B2 falharam porque o serviço estava indisponível durante a preparação do teste, e um teste PUT do Backblaze B2 falhou por causa de timeout de DNS/I/O.

7.4 Benchmark de um dia para LIST,HEAD e DELETE

LIST, HEAD e DELETE usaram o mesmo conjunto de provedores, a mesma origem de teste US East e o mesmo nível de concorrência de 10 workers, mas seus desenhos de execução diferiam. LIST e HEAD eram testes baseados em duração que rodaram por aproximadamente cinco minutos. DELETE processou um conjunto fixo de objetos e terminou quando esse conjunto foi concluído. Seus resultados são apresentados independentemente e não são combinados com as médias PUT e GET de sete ciclos nem usados para criar uma pontuação geral do provedor.

7.5 Unidades

• Throughput PUT e GET: MiB/s.
• Throughput LIST, HEAD e DELETE: objetos/s.
• Latência de requisição e TTFB: milissegundos.

7.6 Logs completos do benchmark

Para reprodutibilidade e revisão independente, os logs completos das execuções do Warp e os artefatos de benchmark de suporte são referenciados no repositório público abaixo:

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

O repositório fornece o material em nível de execução usado para validar os agregados reportados, investigar execuções excluídas ou com falha e reproduzir os cálculos descritos neste relatório.

8. Limitações

• Uma única localização de cliente e um único caminho de rede; os resultados podem diferir entre regiões, ISPs, clouds ou redes corporativas.
• Cargas de trabalho sintéticas: o Warp oferece repetibilidade, mas não reproduz o mix de requisições, o comportamento do SDK, as tentativas ou a distribuição de chaves de objeto de cada aplicação.
• Período de observação limitado: PUT e GET abrangem sete ciclos; LIST, HEAD e DELETE são instantâneos de um dia.
• Sem análise de custo, durabilidade, recursos, suporte ou egress: este relatório é focado em desempenho.
• Sem comparação de latência por percentil em todos os gráficos: as médias são exibidas por legibilidade; aplicações sensíveis à tail latency devem realizar testes P95/P99 específicos da carga de trabalho.
• Resultados excluídos: as médias são baseadas em amostras válidas e podem ter contagens de amostras desiguais entre provedores e células de carga de trabalho.

O que os resultados mostram

Neste teste em US East, o IDrive^® e2 liderou nas cargas PUT médias e em 9 de 12 cargas GET médias. O Backblaze B2 liderou o GET de 1 thread em 5MiB e 50MiB, e o GET de 5 threads em 5MiB. Os testes operacionais de um dia são separados desses resultados de sete ciclos.

Este relatório não cria uma única pontuação para cada provedor. Diferentes aplicações se importam com coisas diferentes, como upload, download, listagem, exclusão, tamanho do objeto, concorrência, latência, consistência, localização e custo. A melhor forma de usar esses resultados é escolher a operação e a carga de trabalho que correspondem às suas necessidades, e então comparar tanto a média quanto os dados detalhados em nível de execução.