Açıklamalar · iki
Kusursuz giden bir indirme kolay durumdur, ve her istemci onu yetkinlikle halleder. İlginç farklar, gönderinin bir bölümü eksik olduğunda ortaya çıkar; ve bu, temiz durumun düşündürdüğünden çok daha sık olur. Gerçekte olan budur, ve neden bu kadar zamana mal olduğu.
Sorunun biçimi
Bir Usenet gönderisi tek bir dosya değildir. Binlerce küçük makaledir; her biri her sağlayıcının sunucularında bağımsız olarak saklanır, ve indirdiğiniz NZB onların adlarının listesidir. 6.5 GB'lik bir sürüm kabaca 9,000 tanesidir.
Makaleler sıradan nedenlerle kaybolur. Sağlayıcılar onları sabit bir saklama süresince tutar, sonra siler. Bazı sağlayıcılar belirli bir makaleyi baştan hiç almamıştır, çünkü sunucular arası yayılım kusurludur. Ara sıra bir yükleme gönderildiğinde eksiktir, ve bir bölümü hiçbir yerde hiç var olmamıştır. Nedeni ne olursa olsun, sonuç aynıdır: istemciniz bir makale ister, ve yanıt veri değil bir rettir.
Bu, Usenet'e gönderi yapanların hesaba katacağı kadar olağandır. Neredeyse her sürümün yanında eşlik verisi gelir, genellikle PAR2 dosyaları; yani özgün içerikten hesaplanmış fazladan artıklı bilgi. İçeriğin bir kısmı eksikse, yeterince varsa eşlik onu yeniden kurabilir. Tipik bir gönderi yaklaşık %10 eşlik taşır, dolayısıyla bir gönderi kendisinin epey bir bölümünü yitirebilir ve yine de tam olarak kurtarılabilir.
Yani hasarlı bir gönderi genellikle bozuk bir indirme değildir. Tamamlanmadan önce biraz aritmetik gerektiren bir indirmedir. Tek soru, bir istemcinin bunu anlamasının ne kadar sürdüğüdür; ve iki kat ya da daha fazla ayrıştıkları yer tam da burasıdır.
Pahalı kısım
Bir sunucuda bir makale yoksa bir ret döndürür, ve istemci o zaman listenizdeki bir sonraki sunucuyu dener. Bu doğru davranıştır, çünkü ikinci sağlayıcıda çoğu zaman vardır. Bedel, kimsede olmadığında ortaya çıkar.
O durumda istemci tüm sağlayıcı listenizi tek tek dolaşır, ve makalenin gerçekten yok olduğu sonucuna varabilmek için her birinden ret alır. Dolaşım sıralıdır, ve retler sanıldığından yavaştır. Onları doğrudan ölçtük; boştaki bir hatta, hiç içerik hareket etmeden:
| sağlayıcı | olağan bir isteği yanıtlama süresi | eksik bir makaleyi reddetme süresi |
|---|---|---|
| Sağlayıcı A | 77.5 ms | 78.8 ms |
| Sağlayıcı B | 10.5 ms | 454 ms |
| Sağlayıcı C | 10.8 ms | 871 ms |
| Sağlayıcı D | 9.9 ms | 1,227 ms |
| Sağlayıcı E | 10.6 ms | 2,239 ms |
İki şey öne çıkıyor. Birincisi, yayılım muazzam: bir ret, hangi sağlayıcının yanıt verdiğine bağlı olarak 79 ms ile 2.2 saniye arasında bir bedele mal oluyor; neredeyse otuz katlık bir fark. İkincisi, bir sağlayıcı esasen sormanın sürdüğü kadar bir sürede reddederken, bir başkası hayır demek için kendi olağan yanıt süresinin iki yüz katından fazlasını harcıyor. Bu ağ gecikmesi değil, onların tarafında olup biten iştir, ve daha az gidiş gelişle sormak neredeyse hiç yardımcı olmuyor.
Toplayın: artık var olmayan tek bir makale için beş sağlayıcı boyunca tam bir dolaşım yaklaşık 5 saniyeye mal oluyor. Şimdi hasarlı bir gönderide bunun gibi çok sayıda makale olduğunu, ve onları sırayla işleyen bir istemcinin bağlantınız boş beklerken bu bedeli defalarca ödediğini düşünün. İndirme, veriler yavaş geldiği için yavaş değildir. Veriler tamamen gelmeyi bırakmıştır, ve istemci, çıkarmaya yetecek bilgiye zaten sahip olduğu şeyin kendisine söylenmesini beklemektedir.
Çözüm
Kavrayış, retleri hızlandırmak değildir; çünkü sağlayıcılar bizim denetimimizde değil. Yanıtın artık önemsiz hâle geldiği anı fark etmektir.
Bir indirmenin herhangi bir anında istemci iki şey bilir: kaç parçanın hâlâ hesapta olmadığını, ve elinde ne kadar eşlik verisi bulunduğunu. Eldeki eşlik, hâlâ eksik olan her şeyi yeniden kurmaya yetiyorsa, «bu makale kimsede var mı?» sorusunun yanıtı sonucu artık değiştiremez. İster yavaş bir evet ister yavaş bir hayır olsun, dosya her hâlükârda yeniden kurulur. Dolaşımı sürdürmek gecikmeden başka bir şey satın almaz.
Bu yüzden bugünkü yapı o noktada sormayı bırakır ve doğrudan onarıma geçer. Yeniden kurmanın kendisi hızlıdır ve hep öyleydi: yaklaşık 2.3 saniye, 6.5 GB'lik bir gönderide; ve bu rakam ölçtüğümüz her sürümde aynıdır. Kazanılan süre, tamamen artık gerçekleşmeyen bekleyiştir.
| 6.5 GB gönderi, 60 eksik makale | doğrulanmış bir dosyaya kadar geçen süre |
|---|---|
| her sağlayıcının reddetmesini beklemek | 23 s |
| eşlik açığı kapatır kapatmaz durmak | 13 s |
| bunun içinde, asıl onarım aritmetiği | 2.3 s |
Aynı değişiklik hasarsız bir gönderide hiçbir şey yapmaz; bu da düşündüğümüz şeyi yaptığının en açık kanıtıdır: eksik makale yoksa kısaltılacak bir dolaşım da yoktur, ve iki yapı temiz bir 6.5 GB işini aynı 7 saniyede bitirir.
Bu bir takas, bedava bir kazanç değil. Erken onarmak, eşlik verisini atıp sonra daha fazlasını getirmek yerine bellekte tutmak demektir; dolayısıyla ağır hasarlı bir gönderide tepe bellek (RSS) yaklaşık 0.8 GB'den yaklaşık 1.3 GB'ye çıkar, ve sağlayıcılardan kabaca 400 MB daha fazla çekeriz. Hasarsız bir gönderide bellek 0.24 GB'de değişmez. Bunun çoğu kişi için doğru takas olduğunu düşünüyoruz, çünkü bellek yalnızca size on saniye kazandırdığı durumda harcanıyor; ama gerçek bir bedeldir ve bunun için bir ayar vardır.
Ret tablosunda sağlayıcı adları bilerek gizlenmiştir. Bu rakamlar tek bir akşam, tek bir konumdan yapılan tek bir ölçümün özelliğidir; ve farklı dizinleyen ya da kötü bir gecede denk geldiğimiz bir sağlayıcı, tek bir tura dayanılarak yavaş diye etiketlenmemelidir. Sav açısından önemli olan biçimdir: retler muazzam ölçüde değişir, ve toplam, hasarlı bir indirmeye egemen olacak kadar büyüktür. Sağlayıcı başına rakamlar ve ham yoklama çıktısı iç kayıtlarımızdadır, ve bunların açıkladığı uçtan uca sayılar kıyaslama sayfasındadır.