Avrupa'da bir kullanıcı olarak, AWS / CloudFront'un desteklediği bir servisten beklemem gereken indirme hızı nedir? Hangi noktada bir yavaşlık ve kime rapor etmeliyim?
WeTransfer, bir gelen örnek linke Bir olsun örnek indir URL'ye (ağ konsolunda, F12 bulunan). Daha sonra iftophangi sunucunun dosyayı bana sunduğunu ve mtrherhangi bir belirgin sorunun göze çarpmadığını görmek için kullanırım (ana bilgisayardan makineme giden traceroute diğer yoldan farklı olabilir).
Dün, dosya CloudFront'un Madrid kenarından sağlandı server-54-192-61-242.mad50.r.cloudfront.net, indirme gibi bir şeydi ve indirme hızım çoğu zaman 150-200 KiB / s'de kalacak şekilde 300 KiB / s'nin üzerine çıkmadı. Çok yavaş. * Traceroute'u kurtarmadım ama bariz bir paket kaybı veya gecikme olmadı; IIRC paketleri Telia'dan geçti.
Bugün, dosya server-54-240-166-250.lhr5.r.cloudfront.net(Londra'dan) sunuluyor ve evde 1,1 MiB / s, Kuzey Avrupa sunucusunda ortalama 13 MiB / s (ve 25 MiB / s zirvesi) alıyorum. Beklediğim bu.
Amazon / AWS ev sahibini dünden değiştirdi ve şimdi işler işe yaradığında, sorunun kendileriyle birlikte olması daha muhtemel görünüyor. Ancak, AWS istemcisi açıkken indirme hızı yavaştır , hiçbir şey yapmayacaklarını söylüyor. CloudFront docs ve AWS forumları ağ oluşturma / yönlendirme / eşleştirme konularının nasıl rapor edileceği hakkında hiçbir bilgiye sahip değildir. Bu durumda ne yapmalı? Sanırım sadece AWS müşterisi bir şeyi yapma pozisyonunda, ancak raporu alan kişi ağ kurmayı anlayabiliyorsa.
CloudFront Madrid’e yaptığım traceroute şu şekilde:
10.|-- 62-101-124-129.fastres.net 0.0% 50 4.6 13.8 3.5 101.1 20.3
11.|-- 89.96.200.21 0.0% 50 17.6 16.6 2.6 92.9 22.0
12.|-- mno-b2-link.telia.net 4.0% 50 52.6 26.3 13.1 69.2 13.7
13.|-- mei-b1-link.telia.net 0.0% 50 23.7 30.3 20.4 87.7 11.3
14.|-- bcn-b2-link.telia.net 0.0% 50 47.5 53.7 30.2 92.9 16.4
15.|-- mad-b2-link.telia.net 0.0% 50 62.7 57.7 36.1 102.2 14.4
16.|-- mad-b1-link.telia.net 0.0% 50 37.7 42.1 34.3 59.8 5.6
17.|-- a100-ic-314004-mad-b1.c.telia.net 0.0% 50 70.2 58.5 39.7 87.2 12.5
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
21.|-- server-54-192-61-242.mad50.r.cloudfront.net 2.0% 50 71.1 83.5 56.4 156.2 19.5
Traceroute şimdi böyle bir şey:
10.|-- 62-101-124-94.fastres.net 0.0% 50 68.6 79.5 36.1 108.8 15.4
11.|-- 89.96.200.110 0.0% 50 75.9 94.8 46.0 141.8 17.6
12.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
13.|-- 54.239.4.248 2.0% 50 107.2 112.9 71.6 146.7 18.2
14.|-- 54.239.41.135 0.0% 50 112.8 108.7 72.8 147.6 15.0
15.|-- 178.236.3.22 0.0% 50 115.8 102.3 58.4 127.9 16.9
16.|-- 176.32.106.11 4.0% 50 95.8 103.2 73.7 130.7 14.2
17.|-- 176.32.106.11 40.0% 50 110.6 108.6 80.4 136.1 14.7
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- server-54-240-166-250.lhr5.r.cloudfront.net 60.0% 50 88.7 100.0 57.6 131.9 18.0
İlk cevabın not ettiği gibi, dosyanın CloudFront ucunda zaten önbelleğe alınmış olup olmadığı çok önemlidir. İşte bir bayan önbellek örneği (şu anda bant genişliğimi doyurmayı başarıyor):
$ LANG='en' wget -S 'https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip'
--2016-02-27 21:34:39-- https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip
Resolving download.wetransfer.com (download.wetransfer.com)... 54.192.61.62, 54.192.61.196, 54.192.61.80, ...
Connecting to download.wetransfer.com (download.wetransfer.com)|54.192.61.62|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 1449534395
Connection: keep-alive
Server: nginx
Date: Sat, 27 Feb 2016 20:34:39 GMT
Content-Transfer-Encoding: binary
Content-Encoding: none
Cache-Control: private, no-transform, no-store
Allow: GET, HEAD
Accept-Ranges: bytes
Content-Disposition: attachment; filename="wetransfer-f7a203.zip"
X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804
X-Cache: Miss from cloudfront
Via: 1.1 943ab292a0096b706fe263560805857e.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4hEZcZL56GWMBn8z1T2txF-O3TTdrAC6OxCtqVDZUoJREUd9_EBo6A==
Length: 1449534395 (1.3G) [application/octet-stream]
Daha fazla test günü , ben hep gewt X-Cache: Miss from cloudfrontbile aynı kaynağı istemek 6 zamanda, yüzden WeTransfer CloudFront (ya da değil bu boyutta dosyalar) bir şey önbelleğe almadığından emin görünüyor. İlginçtir, X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804indirme düğmesine tıklamaktan elde ettiğim gerçek indirme URL'si değişiklik gösterse de başlık her zaman aynıdır; Viave X-Amz-Cf-Idbaşlıklar da değişir. Bu güncelleme itibariyle, belirli bir indirme URL'sini ilk kez talep ettiğimde çok hızlı, ikincisi çok yavaş, üçüncü 404'ler. Denedim ve iki eşzamanlı indirmeye sahip olabilirim, biri ikinci denemede, diğeri ilk denemede: ilki çok yavaş ve ikincisi çok hızlı olacak, ancak ağ koşulları açıkça aynı.
Kuzey Avrupa sunucumdan bir sınama için https://paste.debian.net/408552/ adresine bakın : indir A * bir URL, B * başka; A-2, A-1'den sonra ve B-2, B-1'den sonradır, ancak B *, A-2 çalışırken başlamıştır. Ancak A-1 ve B-1 çok hızlı, A-2 ve B-2 çok yavaş.
Bu giderek hizmet kalitesi / QoS aka kısma ile ilgili bir sorun gibi görünüyor. CloudFront beni önbellek özlemleriyle boğabilir mi yoksa müşterilerini yalnızca suçlamalı mıyız?
(*) Not: Fastweb ile 10/10 Mb / s FTTH bağlantım var. Mevcut bant genişliği asla bu garantili hızın altına düşmez. ISS'nin QoS azaltmayı uyguladığı bilinmemektedir, ancak bazen İtalya dışında bazı yönlendirme sorunları vardır. Sorunu gözlemlediğimde, bant genişliğimi diğer servislerle doyurma konusunda herhangi bir sorun yaşamadım.
25MiB/sEğer bir varsa10Mb/sçizgiyi?