소개
cloud S3 object storage를 평가하는 일은 최대 throughput만 보는 것으로 끝나지 않습니다. 실제 성능은 제공업체가 동시 업로드, 다양한 object 크기, 메타데이터 조회와 object 삭제 같은 운영 작업을 어떻게 처리하는지에 달려 있습니다. 이 보고서는 각 workload를 개별적으로 분석하여 IDrive® e2가 정확히 어디에서 강점을 보이는지, 그리고 작업에 따라 성능이 어디에서 달라지는지 보여줍니다.
핵심 결과
- IDrive® e2는 테스트한 12개의 PUT workload 구성 전체에서 가장 높은 데이터 전송 속도를 기록했습니다. throughput은 concurrency 증가에 비례해 확장되었으며, 100MiB object를 처리할 때 10 thread에서 최대 1.879,48 MiB/s의 측정 속도에 도달했습니다.
- 데이터 검색 테스트에서 IDrive® e2는 평가된 12개 GET 범주 중 9개에서 선두였고, 10-thread workload에서 최대 1.034,81 MiB/s throughput을 달성했습니다. Backblaze B2는 특정 낮은 concurrency 구성에서 더 높은 throughput을 보였으며, 1-thread (5MiB, 50MiB) 및 5-thread (5MiB) workload에서 우위를 보였습니다.
- 서비스 측 요청 처리 평가에서 IDrive® e2는 평균 9,8 ms의 HEAD latency를 기록했습니다. 재고 관리 작업에서는 LIST 작업을 초당 71.467,78 object 속도로 처리했으며, Time to First Byte (TTFB)는 14 ms로 기록되었습니다.
- DELETE 작업에서 IDrive® e2는 초당 3.475,88 object를 처리했으며, 평균 요청 latency는 290,43 ms였습니다.
- 실행 간 일관성을 측정할 때 AWS S3는 테스트된 제공업체 중 가장 낮은 변동성을 보였으며 Coefficient of Variation (CV)은 6,7%였습니다. Cloudflare R2는 7,3% CV를 기록했고, IDrive® e2는 표준화된 테스트 주기 전반에서 11,5% CV로 동작했습니다.
- 차트는 모든 제공업체에 동일한 색 구성표를 사용하며, IDrive® e2는 royal blue로 표시됩니다. 7주기 PUT/GET 그림과 표는 모두 수동 검증된 benchmark 데이터셋을 기반으로 합니다.
테스트 환경 및 workload
모든 제공업체는 US East의 동일한 Vultr Linux 가상 머신에서 Warp를 사용해 테스트했습니다. PUT 및 GET 테스트는 7개의 날짜별 주기 동안 4개의 object 크기와 3개의 concurrency 수준을 다뤘습니다. LIST와 DELETE는 100.000 object, 256KiB object 크기, 10개의 동시 worker를 사용한 하루짜리 운영 benchmark로 별도 실행되었습니다.
단일 원점에서 테스트하면 서로 다른 하드웨어나 지역으로 인한 변동을 줄이는 데 도움이 되지만, 그만큼 이 결과는 US East 경로만 반영합니다. 제공업체의 endpoint, routing, peering, 서비스 지역은 달라질 수 있습니다. 아래 그림은 테스트 경로와 모든 제공업체에 사용된 일관된 차원을 요약합니다.
위의 workload 시각화는 7주기 PUT 및 GET benchmark에 적용됩니다. LIST와 DELETE는 실행 모델과 관찰 창이 다르므로 7장에서 별도로 문서화됩니다.
다음 섹션에서는 각 테스트 범주를 더 자세히 설명합니다.
업로드(PUT) 성능
다운로드(GET) 성능
1. 업로드(PUT) 성능
PUT는 MiB/s 단위의 지속적인 upload throughput을 측정합니다. 다음 섹션에서는 순차 동작과 동시 확장을 분리하고 유효한 샘플 수와 평균을 함께 보여줍니다.
1.1 1 스레드 PUT 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 4.03 | 2.80 | 9.37 | 0.69 | 6.50 |
| 5MiB | 34.94 | 8.30 | 72.91 | 9.64 | 39.15 |
| 50MiB | 85.59 | 25.50 | 215.43 | 30.63 | 80.53 |
| 100MiB | 124.43 | 34.59 | 307.30 | 43.93 | 103.29 |
IDrive® e2는 1 thread에서 네 가지 object 크기 범주 모두를 이끌었습니다. 평균은 256 KiB에서 9,37 MiB/s부터 100 MiB에서 307,30 MiB/s까지였습니다.
1.2 5 스레드 PUT 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 19.30 | 14.64 | 47.71 | 3.54 | 30.34 |
| 5MiB | 164.63 | 42.55 | 418.12 | 48.80 | 184.54 |
| 50MiB | 479.67 | 134.85 | 1,136.00 | 157.45 | 372.71 |
| 100MiB | 681.09 | 175.01 | 1,400.18 | 219.27 | 517.81 |
IDrive® e2는 5 thread에서 네 가지 object 크기 범주 모두를 이끌었습니다. 평균은 256KiB에서 47,71 MiB/s부터 100MiB에서 1.400,18 MiB/s까지였습니다.
5-thread 테스트는 클라이언트 측에서 중간 수준의 병렬성을 나타내며, 여러 동시 전송을 사용하는 백업, 동기화, 마이그레이션 애플리케이션과 관련이 있을 수 있습니다.
1 thread에서 보인 순위는 concurrency가 증가해도 동일하게 유지되었습니다. 이는 최상위 성능이 단일 전송뿐 아니라 모든 object 크기에서 더 많은 동시 업로드를 처리했다는 의미입니다.
1.3 10 스레드 PUT 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 38.60 | 26.79 | 93.00 | 6.82 | 63.94 |
| 5MiB | 341.31 | 82.91 | 783.96 | 97.96 | 400.30 |
| 50MiB | 1,050.94 | 178.92 | 1,739.53 | 298.89 | 910.76 |
| 100MiB | 1,432.63 | 354.15 | 1,879.48 | 409.76 | 1,147.76 |
IDrive® e2는 10 thread에서 네 가지 object 크기 범주 모두를 이끌었습니다. 평균은 256 KiB에서 93,00 MiB/s부터 100 MiB에서 1.879,48 MiB/s까지였습니다.
10-thread 결과는 이 테스트 매트릭스에서 집계 upload 용량을 가장 강하게 보여줍니다. 큰 object의 PUT throughput은 모든 제공업체에서 크게 증가했지만, 확장 정도는 달랐습니다. 이 값들은 하나의 object가 끝나기를 기다리지 않고 여러 active upload를 유지하는 병렬 백업, 복제, 마이그레이션, 미디어 ingest 워크플로에 가장 적합합니다.
1.4 PUT Concurrency 확장성
확장성 곡선은 worker를 1개에서 10개로 늘릴 때 throughput이 상승하는지를 보여줍니다. 더 큰 object는 연결 및 요청 overhead가 덜 중요해지므로 일반적으로 더 큰 이득을 봅니다. 작은 object에서는 확장성이 주로 요청 처리 overhead에 좌우되며, 100MiB object에서는 지속적인 전송 속도와 동시 stream 활용 정도를 반영합니다.
2. 다운로드(GET) 성능
GET은 시간에 따라 MiB/s 단위로 얼마나 많은 데이터를 다운로드할 수 있는지 측정합니다. PUT과 비교하면 단일 thread GET은 제공업체 간 차이가 더 비슷하지만, 더 많은 thread를 사용하면 차이가 더 분명해집니다.
2.1 1 스레드 GET 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 6.86 | 11.04 | 19.24 | 2.05 | 9.21 |
| 5MiB | 63.36 | 64.87 | 63.13 | 29.88 | 47.59 |
| 50MiB | 60.87 | 221.20 | 114.81 | 69.62 | 67.78 |
| 256KiB | 68.29 | 46.70 | 120.40 | 65.48 | 61.05 |
카테고리 리더: 256KiB: IDrive® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive®e2.
단일 thread GET은 테스트에서 가장 경쟁이 치열한 부분이었습니다. Backblaze B2는 5MiB와 50MiB 범주에서 선두였고, IDrive® e2는 256KiB와 100MiB에서 선두였습니다. 5MiB 결과는 근접했습니다. Backblaze B2는 평균 64,87 MiB/s, AWS S3는 63,36 MiB/s, IDrive® e2는 63,13 MiB/s였습니다.
2.2 5 스레드 GET 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 33.95 | 56.41 | 91.09 | 11.73 | 42.82 |
| 5MiB | 302.32 | 399.49 | 343.10 | 161.32 | 235.83 |
| 50MiB | 409.83 | 462.69 | 528.40 | 423.51 | 328.61 |
| 100MiB | 378.34 | 414.12 | 548.89 | 431.28 | 315.88 |
카테고리 리더: 100MiB: IDrive® e2, 256KiB: IDrive® e2, 50MiB: IDrive® e2, 5MiB: Backblaze B2.
5 thread에서는 Backblaze B2가 5MiB GET에서 399,49 MiB/s로 선두였고, IDrive® e2는 256KiB, 50MiB, 100MiB에서 선두였습니다. 이러한 혼합 결과는 애플리케이션에 맞는 workload 범주를 비교하는 것이 왜 중요한지 보여줍니다.
2.3 10 스레드 GET 처리량
| Object 크기 | AWS | Backblaze B2 | IDrive® e2 | Cloudflare R2 | Wasabi |
|---|---|---|---|---|---|
| 256KiB | 68.70 | 112.31 | 171.43 | 23.62 | 95.45 |
| 5MiB | 590.31 | 492.69 | 617.02 | 321.25 | 467.69 |
| 50MiB | 773.96 | 500.04 | 887.35 | 787.01 | 617.71 |
| 100MiB | 783.22 | 500.82 | 1,034.81 | 832.94 | 633.86 |
카테고리 리더: 100MiB: IDrive® e2, 256KiB: IDrive® e2, 50MiB: IDrive® e2, 5MiB: IDrive® e2.
10 thread에서 IDrive® e2는 256KiB에서 171,43 MiB/s부터 100MiB에서 1.034,81 MiB/s까지 네 가지 GET 크기 범주 전체를 이끌었습니다. 이는 concurrency가 증가할수록 그 우위가 커졌음을 보여줍니다.
2.4 GET Concurrency 확장성
256KiB object의 경우 요청 처리 overhead가 주요 요인입니다. 100MiB object의 경우 지속적인 전송 속도와 병렬성이 더 중요합니다. 이 두 사례는 전체 결과를 해석하는 데 도움이 됩니다. 더 높은 concurrency에서 더 뚜렷한 차이는 많은 활성 읽기 요청이 있는 복원, 콘텐츠 전송, 분석 workload에 특히 중요합니다.
3. 요청 지연 시간
Latency는 Warp로 측정한 요청 완료에 걸리는 평균 시간입니다. latency가 낮을수록 응답이 더 빠릅니다. 제공업체가 전체 throughput은 높더라도 각 요청에는 더 오래 걸릴 수 있으므로 throughput과 latency를 모두 보는 것이 중요합니다.
Latency 차트는 각 object 크기를 별도 패널로 보여주므로 더 큰 50MiB 및 100MiB 값이 작은 object 결과를 보기 어렵게 만들지 않습니다. 제공업체 이름은 세로 축에 고정되어 있고 각 막대에는 값이 표시됩니다. 이 구성은 색상이나 막대 길이만으로 추측하지 않고 결과를 직접 비교하는 데 도움이 됩니다.
4. 일관성
변동 계수, 즉 CV는 benchmark 결과가 평균에 비해 실행마다 얼마나 달라졌는지를 보여줍니다. 낮은 CV는 성능이 더 안정적이고 예측 가능했음을 의미하고, 높은 CV는 실행 간 변동이 더 많았음을 의미합니다.
5. Workload 해석
5.1 작은 object workload
256KiB 테스트는 제공업체가 요청을 어떻게 처리하고, 연결을 재사용하며, 메타데이터를 처리하고, API overhead를 어떻게 관리하는지에 초점을 맞춥니다. 이 결과는 백업 인덱스, 썸네일, 작은 앱 자산, 그리고 많은 작은 object를 포함하는 workload에 가장 적합합니다.
5.2 중간 크기 workload
5MiB 및 50MiB 테스트는 일반적인 백업 파일, 미디어 세그먼트, 앱 번들, 분석 파일을 나타냅니다. 결과는 각 제공업체가 단일 업로드에서 얼마나 효율적인지, 그리고 병렬 업로드가 전체 속도를 얼마나 높일 수 있는지를 보여줍니다.
5.3 큰 object workload
100MiB 테스트는 지속적인 네트워크 및 서비스 데이터 전송에 더 초점을 맞춥니다. 10 thread 결과는 병렬 백업, 복원, 복제, 데이터 이동에 유용하고, 1 thread 결과는 단일 전송에서 무엇을 기대할 수 있는지를 보여줍니다.
5.4 적절한 해석
이 테스트는 US East의 단일 client 결과를 기반으로 합니다. 모든 지역, client 위치, 네트워크 경로, 시간대, SDK 또는 앱 패턴을 포함하지 않습니다. 독자는 자신의 object 크기와 concurrency에 맞는 테스트 사례에 가장 집중해야 합니다.
6. One-Day LIST, HEAD 및 DELETE Benchmark
LIST, HEAD 및 DELETE는 별도의 하루짜리 운영 benchmark로 실행되었습니다. PUT 및 GET 섹션과 달리 이 수치는 7주기 평균이 아닙니다. 각 테스트는 동일한 US East 테스트 원점과 10 동시 worker를 사용했습니다. LIST와 DELETE는 준비된 100.000 object 세트를 사용했으며, HEAD는 요청 대상로 50.000 object를 사용했습니다. LIST와 HEAD는 약 5분 동안 실행되었습니다. DELETE는 고정된 object 세트가 처리될 때까지 계속되었습니다.
6.1 테스트 구성
| Operation | Objects | Object 크기 | Concurrency | Duration |
|---|---|---|---|---|
| LIST | 100,000 | 256KiB | 10 | ~5분 |
| HEAD | 50,000 | 기존 테스트 object | 10 | ~5분 |
| DELETE | 100,000 | 256KiB | 10 | 완료 시까지 |
HEAD의 "50,000 objects"는 메타데이터 요청에 사용할 수 있는 object 세트를 의미합니다. Warp는 시간 기반 테스트가 실행되는 동안 계속 요청을 보내면서 고유 object 수보다 더 많은 HEAD 요청을 완료했습니다.
6.2 LIST 성능
| Provider | 평균 object/s | Request latency (ms) | TTFB (ms) | 중간값 object/s | 가장 빠른 object/s | 가장 느린 object/s |
|---|---|---|---|---|---|---|
| AWS | 29,548.60 | 3,377.70 | 35.00 | 29,763.81 | 31,386.33 | 14,626.21 |
| Backblaze B2 | 41,420.09 | 2,407.00 | 24.00 | 41,297.42 | 49,517.11 | 33,347.67 |
| IDrive® e2 | 71,467.78 | 1,409.90 | 14.00 | 71,142.80 | 85,363.46 | 49,211.47 |
| Cloudflare R2 | 5,939.51 | 16,520.10 | 167.00 | 6,091.22 | 6,172.84 | 972.46 |
| Wasabi | 43,792.99 | 2,290.30 | 23.00 | 44,041.49 | 46,192.76 | 30,062.61 |
IDrive® e2는 71.467,78 object/s로 가장 높은 평균 LIST throughput과 1.409,9 ms로 가장 낮은 평균 LIST 요청 latency를 기록했습니다. 평균 TTFB는 14 ms였습니다. 이 수치는 단 하루의 결과이며 장기 평균으로 간주해서는 안 됩니다.
LIST 성능은 pagination, key traversal, 응답 구성, 그리고 client가 각 페이지를 처리하는 능력에 좌우됩니다. throughput(초당 object 수)은 object 항목이 얼마나 빨리 반환되었는지를 보여주고, 평균 request latency는 각 LIST 요청에 걸리는 시간입니다. TTFB는 첫 응답 데이터가 얼마나 빨리 도착했는지를 보여줍니다. 테스트가 duration 기반이므로, range 차트는 실행 중의 단기 변동도 보여줍니다.
6.3 HEAD 성능
| Provider | 평균 object/s | Request latency (ms) | 중간값 object/s | 가장 빠른 object/s | 가장 느린 object/s | 완료 시간 |
|---|---|---|---|---|---|---|
| AWS | 475.95 | 21.10 | 481.23 | 531.32 | 379.44 | 4m57s |
| Backblaze B2 | 770.76 | 12.90 | 784.57 | 918.04 | 501.61 | 4m57s |
| IDrive® e2 | 1,017.80 | 9.80 | 1,020.70 | 1,088.53 | 836.49 | 4m57s |
| Cloudflare R2 | 98.24 | 101.90 | 98.80 | 103.35 | 82.69 | 4m57s |
| Wasabi | 691.42 | 14.50 | 698.52 | 741.03 | 558.54 | 4m57s |
IDrive® e2는 1.017,80 object/s의 가장 높은 평균 HEAD throughput과 9,8 ms의 가장 낮은 평균 요청 latency를 기록했습니다. Backblaze B2는 770,76 object/s로 2위였고, 그 뒤를 Wasabi 691,42 object/s, AWS S3 475,95 object/s, Cloudflare R2 98,24 object/s가 이었습니다. 다섯 제공업체 모두 보고된 오류 없이 테스트를 완료했습니다.
6.4 DELETE 성능
| Provider | 평균 object/s | Request latency (ms) | 중간값 object/s | 가장 빠른 object/s | 가장 느린 object/s | 완료 시간 |
|---|---|---|---|---|---|---|
| AWS | 1,032.09 | 967.98 | 1,038.56 | 1,128.34 | 818.56 | 1m37s |
| IDrive® e2 | 3,475.88 | 290.43 | 3,560.97 | 4,366.62 | 2,069.22 | 29s |
| Cloudflare R2 | 2,022.16 | 495.89 | 2,023.71 | 2,118.75 | 1,912.33 | 50s |
| Wasabi | 815.72 | 1,226.08 | 817.09 | 834.96 | 779.91 | 2m03s |
IDrive® e2는 비교 가능한 DELETE throughput에서 3.475,88 object/s로 가장 높고 평균 요청 latency는 290,43 ms로 가장 낮았습니다. Cloudflare R2는 평균 throughput 2.022,16 object/s와 latency 495,89 ms로 2위였고, AWS S3 1.032,09 object/s, Wasabi 815,72 object/s가 뒤를 이었습니다.
참고: Backblaze B2는 B2 bucket이 본질적으로 versioned이며 일반적인 non-versioned 모드를 지원하지 않으므로 DELETE 비교에서 제외되었습니다. Warp의 표준 DELETE benchmark는 개별 version ID를 열거하고 삭제하지 않고 이름 기반 DELETE 요청을 보냅니다. B2에서는 이러한 요청이 저장된 object version을 영구적으로 제거하는 대신 delete marker를 생성하므로, non-versioned DELETE 작업과 직접 비교하기에는 결과가 부적절합니다.
6.5 LIST/HEAD/DELETE 주의사항
- 이는 하루짜리 비교이며 일간 일관성을 보여주지 않습니다.
- LIST와 HEAD는 duration 기반 테스트이고, DELETE는 고정된 object 세트가 처리된 후 완료됩니다. 따라서 throughput과 완료 동작은 별도로 해석해야 합니다.
- 공급자 측 pagination, listing 구현, delete batching, throttling, bucket 구성은 결과에 중대한 영향을 줄 수 있습니다.
- 이 수치는 테스트된 설정의 운영 스냅샷이며 7주기 PUT/GET 결과와는 분리됩니다.
7. 방법론 및 품질 관리
7.1 7주기 PUT 및 GET benchmark
benchmark는 US East의 Vultr Linux VM 하나에서 Warp를 사용했습니다. 각 제공업체는 동일한 작업, object 크기, concurrency, 지속 시간 조합을 받았습니다. 매트릭스는 제공업체당 주기당 24개의 workload 구성을 포함했습니다. 즉 두 작업, 네 object 크기, 세 thread 수준입니다. 각 workload는 5분 동안 실행되었습니다.
각 테스트 주기는 동일한 workload 차원을 유지하여 일별 결과를 동일 기준으로 집계할 수 있도록 했습니다. PUT과 GET은 256KiB, 5MiB, 50MiB, 100MiB에서 1, 5, 10 동시 worker를 사용해 독립적으로 평가되었습니다. 각 workload는 5분 동안 실행되었습니다. 이 설계는 근본적으로 다른 object 크기나 concurrency 수준을 하나의 점수로 합치지 않으면서 순차적 관찰과 병렬 관찰을 모두 제공합니다.
7.2 유효한 결과 기준
Warp가 유효한 숫자 throughput 측정을 포함한 완전한 최종 보고서를 생성하면 run 수준 결과가 포함되었습니다. Warp가 이미 benchmark를 완료하고 사용 가능한 최종 통계를 생성한 경우, wrapper의 비영(0이 아닌) 종료 코드나 wrapper timeout은 결과를 자동으로 무효화하지 않았습니다. 테스트 준비 중 실패, 서비스 사용 불가 오류, benchmark 실행을 막는 DNS 또는 네트워크 timeout 등 완전한 최종 숫자 결과가 없을 때는 run이 제외되었습니다.
7.3 집계
각 제공업체-workload 셀에 대해 보고서는 유효한 run 수준 throughput 값의 산술 평균을 계산합니다. 결과가 제외된 곳에서는 샘플 수가 달라집니다. latency 값은 동일한 workload 셀의 유효한 결과에서 파생됩니다.
누락된 결과를 0으로 바꾸지 않는 이유는 성능과 테스트 완료를 혼합해 평균을 인위적으로 낮추기 때문입니다. 대신 제외된 결과는 샘플 수와 가용성 보고에서 계속 보입니다. 부록의 7주기 매트릭스는 run 수준 보기를 유지하여 독자가 요약 표와 차트 뒤의 개별 관측치를 볼 수 있게 합니다.
Wasabi와 Backblaze B2에서 9개의 불완전한 run이 확인되었습니다. Wasabi PUT 테스트 3개는 Warp timeout에 도달했고, Backblaze B2 GET 테스트 5개는 테스트 준비 중 서비스가 사용 불가능해서 실패했으며, Backblaze B2 PUT 테스트 1개는 DNS lookup/I/O timeout 때문에 실패했습니다.
7.4 하루짜리 LIST,HEAD 및 DELETE benchmark
LIST, HEAD, DELETE는 동일한 제공업체 집합, US East 테스트 원점, 10-worker concurrency 수준을 사용했지만 실행 설계는 달랐습니다. LIST와 HEAD는 약 5분 동안 실행되는 duration 기반 테스트였습니다. DELETE는 고정된 object 세트를 처리했고 해당 세트가 완료되면 종료되었습니다. 결과는 독립적으로 제시되며 7주기 PUT 및 GET 평균과 결합되거나 전체 제공업체 점수를 만드는 데 사용되지 않습니다.
7.5 단위
- PUT 및 GET throughput: MiB/s.
- LIST, HEAD 및 DELETE throughput: object/s.
- Request latency 및 TTFB: 밀리초.
7.6 전체 Benchmark 로그
재현성과 독립 검토를 위해, 전체 Warp 실행 로그와 지원 benchmark 산출물은 아래 공개 저장소에 참조되어 있습니다:
전체 Warp benchmark 로그: https://github.com/e2-idrive/s3-benchmark-logs
저장소는 보고된 집계를 검증하고, 제외되거나 실패한 실행을 조사하며, 이 보고서에 설명된 계산을 재현하는 데 사용된 run 수준 자료를 제공합니다.
8. 제한 사항
- 단일 client 위치와 네트워크 경로: 결과는 지역, ISP, cloud 또는 기업 네트워크에 따라 달라질 수 있습니다.
- 합성 workload: Warp는 재현성을 제공하지만 모든 애플리케이션의 요청 혼합, SDK 동작, 재시도, object-key 분포를 재현하지는 않습니다.
- 제한된 관찰 기간: PUT 및 GET은 7주기를 다루며, LIST, HEAD, DELETE는 하루짜리 스냅샷입니다.
- 비용, 내구성, 기능, 지원 또는 egress 분석 없음: 이 보고서는 성능 중심입니다.
- 모든 차트에 대한 백분위 latency 비교 없음: 가독성을 위해 평균을 표시했습니다. tail latency에 민감한 애플리케이션은 workload별 P95/P99 테스트를 수행해야 합니다.
- 제외된 결과: 평균은 유효한 샘플을 기반으로 하며 제공업체 및 workload 셀 간에 샘플 수가 같지 않을 수 있습니다.
결과가 보여주는 것
이 US East 테스트에서 IDrive® e2는 평균 PUT workload와 12개의 평균 GET workload 중 9개에서 선두였습니다. Backblaze B2는 5MiB와 50MiB의 1-thread GET, 그리고 5MiB의 5-thread GET에서 선두였습니다. 하루짜리 운영 테스트는 이러한 7주기 결과와 별도입니다.
이 보고서는 각 제공업체에 대해 하나의 점수를 만들지 않습니다. 애플리케이션마다 upload, download, listing, deletion, object 크기, concurrency, latency, 일관성, 위치, 비용 등 중요하게 보는 것이 다릅니다. 이 결과를 사용하는 가장 좋은 방법은 필요에 맞는 작업과 workload를 고른 뒤 평균과 상세 run 수준 데이터를 함께 비교하는 것입니다.
