Giriş
Cloud S3 object storage'ı değerlendirmek, en yüksek throughput'tan çok daha fazlasını kapsar. Gerçek dünya performansı, bir sağlayıcının eşzamanlı upload'ları, değişken object boyutlarını ve metadata alımı ile object silme gibi operasyonel görevleri nasıl yönettiğine bağlıdır. Bu rapor, her workload'u ayrı ayrı ele alarak IDrive® e2'nin tam olarak nerede öne çıktığını ve performansın işleve göre nerede değiştiğini gösterir.
Temel Bulgular
- IDrive® e2, test edilen 12 PUT workload yapılandırmasının tamamında en yüksek veri aktarım oranlarını kaydetti. Throughput, artan concurrency ile orantılı olarak ölçeklendi ve 100MiB object'leri işlerken 10 thread'de 1.879,48 MiB/s maksimum ölçülen hıza ulaştı.
- Veri alma testlerinde IDrive® e2, değerlendirilen 12 GET kategorisinin 9'unda lider oldu ve 10-thread workload'larda 1.034,81 MiB/s tepe throughput elde etti. Backblaze B2, belirli düşük concurrency yapılandırmalarında daha yüksek throughput gösterdi ve 1-thread (5MiB, 50MiB) ile 5-thread (5MiB) workload'larda avantaj sağladı.
- Servis tarafı istek işleme değerlendirmelerinde IDrive® e2, ortalama 9,8 ms HEAD latency kaydetti. Envanter yönetimi görevlerinde servis, LIST operasyonlarını saniyede 71.467,78 object hızında işledi ve Time to First Byte (TTFB) 14 ms olarak kaydedildi.
- DELETE operasyonlarında IDrive® e2, saniyede 3.475,88 object işledi ve ortalama istek latency'si 290,43 ms oldu.
- Çalıştırmalar arası tutarlılık ölçümünde AWS S3, test edilen sağlayıcılar arasında %6,7 Coefficient of Variation (CV) ile en düşük varyansı gösterdi. Cloudflare R2 %7,3 CV kaydederken, IDrive® e2 standartlaştırılmış test döngülerinde %11,5 CV ile çalıştı.
- Grafiklerde tüm sağlayıcılar için aynı renk şeması kullanılır; IDrive® e2 royal blue ile gösterilir. Tüm yedi döngülü PUT/GET şekilleri ve tabloları, manuel olarak doğrulanmış benchmark veri setine dayanır.
Test Ortamı ve Workload
Tüm sağlayıcılar aynı Vultr Linux sanal makinesinden US East'te Warp kullanılarak test edildi. PUT ve GET testleri, yedi tarihli döngü boyunca dört object boyutu ve üç concurrency seviyesi kapsadı. LIST ve DELETE, 100.000 object, 256KiB object boyutu ve 10 eşzamanlı worker kullanılarak ayrı bir tek günlük operasyonel benchmark olarak çalıştırıldı.
Tek bir başlangıç noktasından test yapmak, farklı donanım veya bölgelere bağlı değişkenliği azaltmaya yardımcı olur; ancak bu sonuçların yalnızca US East yolunu yansıttığı anlamına gelir. Sağlayıcı endpoint'leri, routing, peering ve servis bölgeleri değişebilir. Aşağıdaki görseller, test yolunu ve tüm sağlayıcılar için kullanılan tutarlı boyutları özetler.
Yukarıdaki workload görselleştirmesi, yedi döngülü PUT ve GET benchmark'ına uygulanır. LIST ve DELETE, yürütme modeli ve gözlem penceresi farklı olduğundan 7. Bölümde ayrı olarak belgelenir.
Aşağıdaki bölümler her test kategorisini daha ayrıntılı açıklar.
Upload (PUT) Performansı
Download (GET) Performansı
1. Upload (PUT) Performansı
PUT, MiB/s cinsinden sürdürülebilir upload throughput'unu ölçer. Aşağıdaki bölümler sıralı davranışı eşzamanlı ölçeklenmeden ayırır ve geçerli örnek sayılarıyla ortalamaları gösterir.
1.1 1 Thread PUT Throughput
| Object boyutu | 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'de dört object boyutu kategorisinin tamamında liderdi. Ortalaması 256 KiB'de 9,37 MiB/s ile 100 MiB'de 307,30 MiB/s arasında değişti.
1.2 5 Thread PUT Throughput
| Object boyutu | 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'de dört object boyutu kategorisinin tamamında liderdi. Ortalaması 256KiB'de 47,71 MiB/s ile 100MiB'de 1.400,18 MiB/s arasında değişti.
Beş thread'li test, istemci tarafında orta düzey eşzamanlılığı temsil eder ve birden fazla eşzamanlı transfer kullanan yedekleme, senkronizasyon ve taşıma uygulamaları için relevant olabilir.
Bir thread ile görülen sıralama, concurrency arttıkça aynı kaldı. Bu, en iyi performans gösterenin yalnızca tekil transferlerde değil, tüm object boyutlarında daha fazla eşzamanlı upload'ı yönetebildiği anlamına gelir.
1.3 10 Thread PUT Throughput
| Object boyutu | 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'de dört object boyutu kategorisinin tamamında liderdi. Ortalaması 256 KiB'de 93,00 MiB/s ile 100 MiB'de 1.879,48 MiB/s arasında değişti.
On thread sonuçları, bu test matrisinde toplam upload kapasitesinin en güçlü göstergesidir. Büyük object'ler için PUT throughput'u tüm sağlayıcılarda önemli ölçüde arttı, ancak ölçeklenme derecesi değişti. Bu değerler, tek bir object'in bitmesini beklemek yerine birden fazla aktif upload'ı sürdüren paralel yedekleme, çoğaltma, taşıma ve medya alma iş akışları için en anlamlıdır.
1.4 PUT Concurrency Ölçeklenmesi
Ölçeklenme eğrileri, birden 10'a daha fazla worker eklendikçe throughput'un yükselip yükselmediğini gösterir. Daha büyük object'ler genellikle daha fazla kazanç görür; çünkü bağlantı ve istek overhead'i daha az önem taşır. Küçük object'lerde ölçeklenme çoğunlukla istek işleme overhead'ine bağlıyken, 100MiB object'lerde sürdürülebilir transfer hızını ve eşzamanlı stream'lerin ne kadar iyi kullanıldığını yansıtır.
2. Download (GET) Performansı
GET, zaman içinde MiB/s cinsinden ne kadar veri indirilebileceğini ölçer. PUT'a kıyasla, tek thread GET sağlayıcılar arasında daha benzerdir; ancak daha fazla thread kullanıldığında farklar daha net hale gelir.
2.1 1 Thread GET Throughput
| Object boyutu | 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 |
Kategori liderleri: 256KiB: IDrive® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive®e2.
Tek thread GET, testin en rekabetçi kısmıydı. Backblaze B2, 5MiB ve 50MiB kategorilerinde liderlik etti; IDrive® e2 ise 256KiB ve 100MiB'de liderdi. 5MiB sonuçları yakındı: Backblaze B2 ortalama 64,87 MiB/s, AWS S3 63,36 MiB/s ve IDrive® e2 63,13 MiB/s elde etti.
2.2 5 Thread GET Throughput
| Object boyutu | 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 |
Kategori liderleri: 100MiB: IDrive® e2, 256KiB: IDrive® e2, 50MiB: IDrive® e2, 5MiB: Backblaze B2.
Beş thread ile Backblaze B2, 5MiB GET'te 399,49 MiB/s ile liderdi; IDrive® e2 ise 256KiB, 50MiB ve 100MiB'de liderdi. Bu karışık sonuçlar, uygulamanızla eşleşen workload kategorisini karşılaştırmanın neden önemli olduğunu gösterir.
2.3 10 Thread GET Throughput
| Object boyutu | 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 |
Kategori liderleri: 100MiB: IDrive® e2, 256KiB: IDrive® e2, 50MiB: IDrive® e2, 5MiB: IDrive® e2.
On thread ile IDrive® e2, 256KiB'de 171,43 MiB/s'den 100MiB'de 1.034,81 MiB/s'ye kadar dört GET boyut kategorisinin tamamında liderdi. Bu, avantajının concurrency arttıkça büyüdüğünü gösterir.
2.4 GET Concurrency Ölçeklenmesi
256KiB object'ler için istek işleme overhead'i ana faktördür. 100MiB object'ler için sürdürülebilir transfer hızı ve paralellik daha önemlidir. Bu iki durum, tüm sonuçları yorumlamaya yardımcı olur. Daha yüksek concurrency'deki daha net farklar, çok sayıda aktif okuma isteği içeren restore, content delivery ve analiz workload'ları için özellikle önemlidir.
3. Request Latency
Latency, Warp tarafından ölçülen bir isteği tamamlamak için geçen ortalama süredir. Daha düşük latency daha hızlı yanıtlar anlamına gelir. Bir sağlayıcı yüksek toplam throughput'a sahip olsa da her istek için daha uzun sürebileceğinden, hem throughput'a hem latency'ye bakmak önemlidir.
Latency grafikleri her object boyutunu ayrı bir panelde gösterir; böylece daha büyük 50MiB ve 100MiB değerleri küçük object sonuçlarını okunmaz hale getirmez. Sağlayıcı adları dikey eksende sabit kalır ve her çubuk değeriyle etiketlenir. Bu düzen, renkler veya çubuk uzunluklarından tahmin yürütmeden doğrudan karşılaştırmayı kolaylaştırır.
4. Tutarlılık
Varyasyon katsayısı veya CV, benchmark sonuçlarının ortalamaya kıyasla çalıştırmadan çalıştırmaya ne kadar değiştiğini gösterir. Daha düşük CV, performansın daha stabil ve öngörülebilir olduğu anlamına gelir; daha yüksek CV ise çalıştırmalar arasında daha fazla değişkenlik olduğunu gösterir.
5. Workload Yorumu
5.1 Küçük object workload'ları
256KiB testleri, sağlayıcıların istekleri nasıl ele aldığını, bağlantıları nasıl yeniden kullandığını, metadata'yı nasıl işlediğini ve API overhead'ini nasıl yönettiğini odaklar. Bu sonuçlar, backup dizinleri, thumbnail'lar, küçük uygulama varlıkları ve çok sayıda küçük object içeren workload'lar için en anlamlı olanlardır.
5.2 Orta boy workload'lar
5MiB ve 50MiB testleri tipik backup dosyalarını, medya segmentlerini, uygulama paketlerini ve analiz dosyalarını temsil eder. Sonuçlar, her sağlayıcının tekil upload'larda ne kadar verimli olduğunu ve paralel upload'ların toplam hızı ne kadar artırabileceğini gösterir.
5.3 Büyük object workload'ları
100MiB testleri daha çok sürekli ağ ve servis veri aktarımına odaklanır. 10 thread'li sonuçlar paralel backup, restore, replikasyon ve veri taşıma için yararlıdır; tek thread sonuçları ise tekil transferlerde ne beklenmesi gerektiğini gösterir.
5.4 Uygun yorumlama
Bu testler US East'te tek bir client'ın sonuçlarına dayanır. Her bölgeyi, client konumunu, ağ yolunu, günün saatini, SDK'yı veya uygulama desenini kapsamaz. Okuyucular, en çok kendi object boyutları ve concurrency seviyeleriyle eşleşen test vakalarına odaklanmalıdır.
6. One-Day LIST, HEAD ve DELETE Benchmark
LIST, HEAD ve DELETE ayrı tek günlük operasyonel benchmark'lar olarak çalıştırıldı. PUT ve GET bölümlerinden farklı olarak, bu değerler yedi döngü ortalaması değildir. Her test aynı US East test kaynağını ve 10 eşzamanlı worker'ı kullandı. LIST ve DELETE, hazırlanan 100.000 object setini kullandı; HEAD ise istek hedefi olarak 50.000 object kullandı. LIST ve HEAD yaklaşık beş dakika sürdü. DELETE, sabit object seti işlenene kadar devam etti.
6.1 Test Yapılandırması
| Operation | Objects | Object boyutu | Concurrency | Duration |
|---|---|---|---|---|
| LIST | 100,000 | 256KiB | 10 | ~5 dakika |
| HEAD | 50,000 | Mevcut test object'leri | 10 | ~5 dakika |
| DELETE | 100,000 | 256KiB | 10 | Tamamlanana kadar |
HEAD için "50,000 objects", metadata istekleri için kullanılabilir object setini temsil eder. Warp, süre bazlı test çalıştığı için benzersiz object sayısından daha fazla HEAD isteği tamamladı ve test boyunca istek göndermeye devam etti.
6.2 LIST Performansı
| Provider | Ortalama object/s | Request latency (ms) | TTFB (ms) | Medyan object/s | En hızlı object/s | En yavaş 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 ile en yüksek ortalama LIST throughput'una ve 1.409,9 ms ile en düşük ortalama LIST latency'sine sahipti. Ortalama TTFB'si 14 ms idi. Bu sayılar tek bir güne aittir ve uzun vadeli ortalamalar olarak alınmamalıdır.
LIST performansı, pagination, key traversal, response oluşturma ve client'ın her sayfayı işleme yeteneğine bağlıdır. Throughput (saniyede object) object girişlerinin ne kadar hızlı döndürüldüğünü gösterirken, ortalama request latency her LIST isteği için geçen süredir. TTFB, ilk yanıt verisinin ne kadar hızlı ulaştığını gösterir. Test süreye dayalı olduğundan, aralık grafiği çalıştırma sırasındaki kısa vadeli değişkenliği de gösterir.
6.3 HEAD Performansı
| Provider | Ortalama object/s | Request latency (ms) | Medyan object/s | En hızlı object/s | En yavaş object/s | Tamamlanma süresi |
|---|---|---|---|---|---|---|
| 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 ile en yüksek ortalama HEAD throughput'unu ve 9,8 ms ile en düşük ortalama request latency'sini kaydetti. Backblaze B2, 770,76 object/s ile ikinci sırada yer aldı; onu 691,42 object/s ile Wasabi, 475,95 object/s ile AWS S3 ve 98,24 object/s ile Cloudflare R2 izledi. Beş sağlayıcının tamamı testi bildirilen hata olmadan tamamladı.
6.4 DELETE Performansı
| Provider | Ortalama object/s | Request latency (ms) | Medyan object/s | En hızlı object/s | En yavaş object/s | Tamamlanma süresi |
|---|---|---|---|---|---|---|
| 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, karşılaştırılabilir DELETE throughput'unda 3.475,88 object/s ile en yüksek değere ve 290,43 ms ile en düşük ortalama request latency'sine ulaştı. Cloudflare R2, 2.022,16 object/s ortalama throughput ve 495,89 ms latency ile ikinci sırada yer aldı; onu 1.032,09 object/s ile AWS S3 ve 815,72 object/s ile Wasabi izledi.
Not: Backblaze B2, B2 bucket'ları doğası gereği versioned olduğu ve geleneksel non-versioned modu desteklemediği için DELETE karşılaştırmasından çıkarıldı. Warp'ın standart DELETE benchmark'ı, tek tek version ID'leri listeleyip silmeden ada dayalı DELETE istekleri gönderir. B2'de bu tür istekler, depolanan object sürümlerini kalıcı olarak kaldırmak yerine delete marker oluşturur; bu da sonuçları non-versioned DELETE işlemleriyle doğrudan karşılaştırma için uygun olmayan hale getirir.
6.5 LIST/HEAD/DELETE Uyarıları
- Bu, tek günlük bir karşılaştırmadır ve günden güne tutarlılığı göstermez.
- LIST ve HEAD süre bazlı testlerdir; DELETE ise sabit object seti işlendikten sonra tamamlanır. Bu nedenle throughput ve tamamlanma davranışı ayrı yorumlanmalıdır.
- Sağlayıcı tarafı pagination, listing implementation, delete batching, throttling ve bucket configuration sonuçları önemli ölçüde etkileyebilir.
- Bu değerler test edilen kurulumun operasyonel bir anlık görünümüdür ve yedi döngülü PUT/GET sonuçlarından ayrıdır.
7. Metodoloji ve Kalite Kontrolleri
7.1 Yedi döngülü PUT ve GET benchmark'ı
Benchmark, US East'teki bir Vultr Linux VM'den Warp kullanılarak yapıldı. Her sağlayıcı aynı operasyon, object boyutu, concurrency ve süre kombinasyonlarını aldı. Matris, sağlayıcı başına döngü başına 24 workload yapılandırmasını içeriyordu: iki operasyon, dört object boyutu ve üç thread seviyesi. Her workload beş dakika çalıştı.
Her test döngüsü aynı workload boyutlarını korudu; böylece gün be gün sonuçlar aynı temelde birleştirilebildi. PUT ve GET, 1, 5 ve 10 eşzamanlı worker kullanılarak 256KiB, 5MiB, 50MiB ve 100MiB'de ayrı ayrı değerlendirildi. Her workload beş dakika çalıştı. Bu tasarım, temelde farklı object boyutlarını veya concurrency seviyelerini tek bir puanda birleştirmeden hem sıralı hem paralel gözlemler üretir.
7.2 Geçerli sonuç ölçütleri
Warp geçerli bir sayısal throughput ölçümü içeren eksiksiz bir nihai rapor ürettiğinde bir run seviyesi sonucu dahil edildi. Warp benchmark'ı zaten tamamlamış ve kullanılabilir nihai istatistikler üretmişse, sıfır olmayan bir wrapper çıkış kodu veya wrapper timeout sonucu otomatik olarak geçersiz kılmazdı. Test hazırlığı sırasındaki hatalar, hizmet kullanılamıyor hataları ve benchmark yürütülmesini engelleyen DNS veya network timeout'ları dahil olmak üzere eksiksiz bir nihai sayısal sonuç yoksa run'lar hariç tutuldu.
7.3 Aggregation
Her sağlayıcı-workload hücresi için rapor, geçerli run seviyesi throughput değerlerinin aritmetik ortalamasını hesaplar. Sonuçlar hariç tutulduğunda örnek sayıları değişir. Latency değerleri, aynı workload hücrelerine ait geçerli sonuçlardan türetilir.
Eksik bir sonuç sıfıra çevrilmez; çünkü bu, performansı test tamamlanmasıyla karıştırır ve ortalamayı yapay olarak düşürür. Bunun yerine hariç tutulan sonuçlar örnek sayısında ve kullanılabilirlik raporlamasında görünür kalır. Eklerdeki yedi döngülü matrisler run seviyesindeki görünümü korur ve okuyucuların özet tabloların ve grafiklerin arkasındaki bireysel gözlemleri görmesini sağlar.
Wasabi ve Backblaze B2 arasında dokuz eksik run tespit edildi. Üç Wasabi PUT testi Warp timeout'una ulaştı, beş Backblaze B2 GET testi test hazırlığı sırasında hizmet kullanılamadığı için başarısız oldu ve bir Backblaze B2 PUT testi DNS lookup/I/O timeout nedeniyle başarısız oldu.
7.4 LIST,HEAD ve DELETE için tek günlük benchmark
LIST, HEAD ve DELETE aynı sağlayıcı setini, US East test kaynağını ve 10-worker concurrency seviyesini kullandı; ancak yürütme tasarımları farklıydı. LIST ve HEAD yaklaşık beş dakika süren süre bazlı testlerdi. DELETE sabit bir object setini işledi ve set tamamlandığında sona erdi. Sonuçları bağımsız olarak sunulur ve yedi döngülü PUT ve GET ortalamalarıyla birleştirilmez veya genel bir sağlayıcı puanı oluşturmak için kullanılmaz.
7.5 Birimler
- PUT ve GET throughput: MiB/s.
- LIST, HEAD ve DELETE throughput: object/s.
- Request latency ve TTFB: milisaniye.
7.6 Tam Benchmark Logları
Yeniden üretilebilirlik ve bağımsız inceleme için, tam Warp run log'ları ve destekleyici benchmark artefaktları aşağıdaki genel repoda referanslanmıştır:
Warp tam benchmark logları: https://github.com/e2-idrive/s3-benchmark-logs
Repo, raporlanan aggregate'leri doğrulamak, hariç tutulan veya başarısız run'ları incelemek ve bu raporda açıklanan hesaplamaları yeniden üretmek için kullanılan run seviyesindeki materyali sağlar.
8. Sınırlamalar
- Tek bir client konumu ve network yolu; sonuçlar bölgeler, ISP'ler, cloud'lar veya kurumsal ağlar arasında farklılık gösterebilir.
- Sentetik workload'lar: Warp tekrar edilebilirlik sağlar ancak her uygulamanın request karışımını, SDK davranışını, retry'ları veya object-key dağılımını yeniden üretmez.
- Sınırlı gözlem süresi: PUT ve GET yedi döngü sürer; LIST, HEAD ve DELETE ise tek günlük anlık görüntülerdir.
- Maliyet, dayanıklılık, özellik, destek veya egress analizi yoktur: bu rapor performans odaklıdır.
- Tüm grafiklerde percentile latency karşılaştırması yoktur: okunabilirlik için ortalamalar gösterilmiştir; tail latency'ye duyarlı uygulamalar workload'a özel P95/P99 testleri yapmalıdır.
- Hariç tutulan sonuçlar: ortalamalar geçerli örneklere dayanır ve sağlayıcılar ile workload hücreleri arasında eşit olmayan örnek sayıları olabilir.
Sonuçların Gösterdiği Şey
Bu US East testinde IDrive® e2, ortalama PUT workload'larında ve 12 ortalama GET workload'undan 9'unda lider oldu. Backblaze B2, 5MiB ve 50MiB'de 1 thread GET'te ve 5MiB'de 5 thread GET'te liderdi. Tek günlük operasyonel testler bu yedi döngülü sonuçlardan ayrıdır.
Bu rapor her sağlayıcı için tek bir puan oluşturmaz. Farklı uygulamalar upload, download, listing, deletion, object boyutu, concurrency, latency, tutarlılık, konum ve maliyet gibi farklı şeylere önem verir. Bu sonuçları kullanmanın en iyi yolu, ihtiyaçlarınıza uyan operation ve workload'u seçmek, ardından hem ortalamayı hem de ayrıntılı run seviyesindeki verileri karşılaştırmaktır.
