Bir WAN bağlantısını performans testi için yöntemler

Yaklaşık 200 mil arayla konumlar arasında bir çift yeni çeşitlendirilmiş 1Gbps Ethernet bağlantısı var. 'İstemci' yeni, oldukça güçlü bir makinedir (HP DL380 G6, çift E56xx Xeons, 48GB DDR3, R1 çift 300GB 10krpm SAS diskler, W2K8R2-x64) ve 'sunucu' da yeterince iyi bir makinedir (HP BL460c G6 , çift E55xx Xeons, 72GB, R1 çift 146GB 10krpm SAS diskler, çift Cisco MDS9509'lara bağlanan çift bağlantı noktalı Emulex 4Gbps FC HBA ve daha sonra 128 x 450GB 15krpm FC disklerle özel HP EVA 8400'e, RHEL 5.3-x64).

İstemciden SFTP kullandığımızda, büyük (> 2GB) dosyalar kullanarak yalnızca 40Kbps'lik bir iş hacmi görüyoruz. 'Diğer yerel sunucu' testlerine sunucu uyguladık ve yerel anahtarlar (Cat 6509s) üzerinden yaklaşık 500Mbps görüyoruz, istemci tarafında da aynısını yapacağız, ancak bu bir gün kadar uzakta.

Bağlantı sağlayıcılara sorunun kendilerine ait olduğunu kanıtlamak için başka hangi test yöntemlerini kullanırsınız?

Bir Filin Ayarlanması:
Bu ayarlamayı gerektirebilir, muhtemelen pQd'nin dediği gibi burada sorun değil. Bu tür bir bağlantı "Uzun, Yağ Borusu" veya fil olarak bilinir (bkz. RFC 1072 ). Bu, bir mesafeden geçen bir yağ gigabit borusu olduğundan (bu durumda mesafe gerçekten zaman / gecikme süresidir), tcp alma penceresinin büyük olması gerekir (Resimler için bkz. TCP / IP Illustrated Volume 1, TCP Uzantıları Bölümü).

Alıcı penceresinin ne olması gerektiğini anlamak için bant genişliği gecikme ürününü hesaplarsınız:

Bandwidth * Delay = Product

10MS gecikme süresi varsa, bu hesap makinesi yaklaşık 1.2 MBytes'lik bir alma penceresi istediğinizi tahmin eder. Hesaplamayı yukarıdaki formülle kendimiz yapabiliriz:

echo $(( (1000000.00/.01)/8  )) 
12500000

Bu nedenle, tcp pencere ölçeklendirmesinin (daha büyük pencerelere izin veren TCP uzantısı) büyük sorunun ne olduğunu anladıktan sonra bunu ayarlamak için doğru olup olmadığını görmek için bir paket dökümü çalıştırmak isteyebilirsiniz .

Pencereye Bağlı:
Sorun buysa, ölçeklendirme olmadan pencere boyutuna bağlı olursanız, Pencere ölçeklemesi yerinde değilse ve boru boyutundan bağımsız olarak yaklaşık 200 ms gecikme varsa aşağıdaki sonuçları beklerim:

Throughput = Recieve Window/Round Trip Time

Yani:

echo $(( 65536/.2 ))
327680 #Bytes/second

Gördüğünüz sonuçları elde etmek için, gecikme için çözmeniz gerekir;

RTT = RWIN/Throughput

Yani (40 kByte / s için):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Lütfen Math'ımı kontrol edin ve bunlar elbette tüm protokol / başlık ek yükünü içermez)

40kbps çok düşük [hatalı medya dönüştürücüler / dubleks uyumsuzluğu şüphelenir noktaya kadar [ama gigabit var yani yarım dubleks için yer yok!] Vb]. paket kayıpları veya çok yüksek titreşim olması gerekir.

iperf mevcut iş hacmini ölçmek için aklıma gelen ilk araçtır. bir taraftan koş

iperf -s 

ve diğer yandan:

iperf -t 60 -c 10.11.12.13

daha sonra istemci / sunucu rollerini değiştirebilir, dubleks için -d kullanabilirsiniz vb. test başlamadan önce her iki makine arasında mtr çalıştırabilir ve kullanılmayan bağlantıda hangi gecikme / paket kayıplarını ve veri aktarımı sırasında nasıl değiştiğini görebilirsiniz.

görmek istersiniz: bağlantı kapasitesinin yüzde 90'ına doyuncaya kadar çok küçük titreşim ve paket kaybı yok.

* nix için iperf ve kazan , burada ve burada okuyun .

* nix için mtr ve kazanın .

tracepath size iki site arasındaki yönlendirme sorunlarını gösterebilir.

iperf, ttcp ve bwping size faydalı bilgiler verebilir.

Bu 1GB bağlantısının nasıl sağlandığını biliyor musunuz? bu bağlantı üzerinden köprülüyor veya yönlendiriyor musunuz? Bağlantı için SLA'nız nedir? bağlantı sağlayıcınız tarafından şekillendirilebilir misiniz?

sadece 40kbs alıyorsanız, ciddi bir sorun var, bunun 1GB / s bağlantısı yerine 1MB'nin bağlantısı olmadığından emin misiniz? Muhtemelen bağlantının hızının düşündüğünüz gibi olmadığını göreceksiniz :-)

RFC 2544 veya Y.156sam

Bunlar, taşıyıcı tarafından SLA'yı kanıtlamak için yapılan ağ testleridir. IPERF ve benzerleri doğrulanabilir ağ test yöntemleri değildir.