Metodologi untuk menguji kinerja tautan WAN

11

Kami memiliki sepasang tautan Ethernet 1Gbps yang dialihkan secara beragam antara lokasi yang jaraknya sekitar 200 mil. 'Klien' adalah mesin baru yang cukup kuat (HP DL380 G6, dual E56xx Xeon, 48GB DDR3, sepasang R1 SAS 300GB 10krpm disk, W2K8R2-x64) dan 'server' juga merupakan mesin yang cukup layak (HP BL460c G6 , dual E55xx Xeons, 72GB, R1 sepasang 146GB 10krpm SAS disk, dual-port Emulex 4Gbps FC HBA yang ditautkan ke dual Cisco MDS9509s kemudian ke HP EVA 8400 khusus dengan disk FC 128k 450GB 15krpm, RHEL 5.3-x64).

Menggunakan SFTP dari klien, kami hanya melihat sekitar 40Kbps throughput menggunakan file besar (> 2GB). Kami telah melakukan uji coba server untuk 'server lokal lain' dan melihat sekitar 500Mbps melalui sakelar lokal (Cat 6509), kami akan melakukan hal yang sama di sisi klien, tetapi itu tinggal beberapa hari lagi.

Apa metode pengujian lain yang akan Anda gunakan untuk membuktikan kepada penyedia tautan bahwa masalahnya adalah masalah mereka?

networking performance sftp

— Chopper3
sumber

Saya juga ingin tahu jawaban untuk yang ini. Kami mendapatkan leased line 100Mbit kami dipasang minggu depan kapan saja :)

— Tom O'Connor

seperti kata user37899 - hasilnya akan dihargai.

— pQd

Adakah pembaruan? Saya ingin tahu bagaimana yang ini ternyata.

— Kyle Brandt

Saya memukuli penyedia tautan "dengan sangat buruk" (ironisnya mereka adalah bagian dari organisasi yang sama dengan tempat saya bekerja!) - mereka belum kembali kepada kami.

— Chopper3

1

Ah oke, dan omong-omong, jika Anda bisa mencari tahu mengapa saya mendapatkan 7 suara untuk serverfault.com/questions/134467/… dan 1 untuk ini, saya ingin tahu ;-)

— Kyle Brandt

10

Tuning an Elephant:
Ini bisa membutuhkan tuning, mungkin bukan masalah di sini seperti yang dikatakan pQd. Tautan semacam ini dikenal "Long, Fat Pipe" atau gajah (lihat RFC 1072 ). Karena ini adalah pipa gigabit gemuk yang melewati suatu jarak (jarak ini benar-benar waktu / latensi dalam kasus ini), jendela penerima tcp harus besar (Lihat TCP / IP Illustrated Volume 1, Bagian Perpanjangan TCP untuk gambar).

Untuk mengetahui seperti apa seharusnya jendela penerima, Anda menghitung produk penundaan bandwidth:

Bandwidth * Delay = Product

Jika ada 10MS latensi, kalkulator ini memperkirakan Anda ingin menerima jendela sekitar 1,2 MB. Kita dapat melakukan perhitungan sendiri dengan rumus di atas:

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

Jadi, Anda mungkin ingin menjalankan dump paket untuk melihat apakah penskalaan jendela tcp (ekstensi TCP yang memungkinkan untuk jendela yang lebih besar) sedang terjadi untuk menyetel ini begitu Anda mengetahui apa pun masalahnya yang besar.

Batas Jendela:
Jika ini masalahnya, bahwa Anda terikat dengan ukuran jendela tanpa penskalaan, saya akan mengharapkan hasil berikut jika tidak ada penskalaan jendela di tempat dan ada sekitar 200 ms latensi terlepas dari ukuran pipa:

Throughput = Recieve Window/Round Trip Time

Begitu:

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

Untuk mendapatkan hasil yang Anda lihat, Anda hanya perlu menyelesaikan latensi, yaitu:

RTT = RWIN/Throughput

Jadi (Untuk 40 kBytes / s):

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

(Silakan periksa Matematika saya, dan ini tentu saja tidak termasuk semua overhead protokol / header)

— Kyle Brandt
sumber

Anda tahu saya merasa sedikit bersalah karena 'menyalip' Anda untuk sementara waktu minggu lalu, dan alasannya adalah karena seberapa bagus jawaban Anda - dan BOOM! Anda bahkan menggunakan shell untuk menghitung, bukan Mac Calculator 1.5MB yang saya lakukan! :) Terima kasih.

— Chopper3

1

Anda memiliki jawaban yang baik juga, dan saya suka bahwa saya memiliki seseorang yang dekat dengan saya dalam rep, meningkatkan permainan sedikit :-) Permintaan google cepat mengingatkan saya bahwa Anda telah menjawab pertanyaan saya juga: serverfault.com/questions/107263/ ... . Saya sangat menghargai pengguna aktif yang mencoba membuat komunitas ini 'terjadi'. Tapi terima kasih atas komplemennya!

— Kyle Brandt

Saya juga, tidak ada yang saya sukai selain mengetahui bahwa kami telah membantu seseorang yang merasa mereka sendiri dengan masalah yang membuat frustrasi - selain keju tentu saja. Yang mengatakan saya benci ketika kita mendapatkan pertanyaan yang dibentuk dengan buruk juga, apakah Anda mendengar pertanyaan saya di SO podcast 82? dapatkan kaos SF gratis juga!

— Chopper3

Saya mendengarkan sebagian besar podcast tetapi melewatkan yang satu itu, akan kembali dan memeriksanya (mungkin akhir pekan ini).

— Kyle Brandt

Maaf tentang pQd itu, saya sebenarnya selalu membaca nick Anda sebagai PDQ seperti pada PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40kbps sangat rendah [sampai-sampai saya curiga konverter media yang salah / dupleks tidak cocok [tetapi Anda memiliki gigabit sehingga tidak ada tempat untuk setengah dupleks!] Dll]. harus ada paket loss atau jitter yang sangat tinggi.

iperf adalah alat pertama yang muncul di pikiran saya untuk mengukur throughput yang tersedia. lari di satu sisi

iperf -s

dan di sisi lain:

iperf -t 60 -c 10.11.12.13

kemudian Anda dapat bertukar peran klien / server, gunakan -d untuk dupleks dll. jalankan mtr antara kedua mesin sebelum memulai tes dan lihat latensi / paket kerugian yang Anda miliki pada tautan yang tidak digunakan, dan bagaimana mereka berubah selama transfer data.

Anda ingin melihat: jitter yang sangat kecil dan tidak ada paket yang hilang sampai link jenuh pada 90-sesuatu persen dari kapasitasnya.

iperf untuk * nix dan menang , baca di sini dan di sini tentang hal itu.

mtr untuk * nix dan menang .

— pQd
sumber

Kita tahu bahwa tautan tersebut terdiri dari 6 tautan 1000-base-zx sehingga pasti ada latensi yang diperkenalkan oleh semua pengulangan itu, tetapi meskipun demikian saya terkejut karena Anda betapa rendahnya, banyak tip tentang hal iperf oleh cara, saya benar-benar lupa itu ada!

— Chopper3

tolong kirim hasil Anda!

— The Unix Janitor

1

tracepath dapat menunjukkan masalah perutean antara kedua situs.

iperf, ttcp dan bwping dapat memberikan Anda informasi yang bermanfaat.

apakah Anda tahu bagaimana tautan 1GB ini disediakan? apakah Anda menjembatani atau merutekan melalui tautan ini? Apa SLA Anda untuk tautan? Anda bisa dibentuk oleh penyedia tautan Anda?

jika Anda hanya mendapatkan 40kbs, maka ada masalah serius, apakah Anda yakin itu bukan tautan 1MB dan bukan tautan 1GB / s. Anda mungkin akan menemukan bahwa kecepatan tautannya tidak seperti yang Anda pikirkan :-)

— Unix Janitor
sumber

Terima kasih atas jawaban Anda, ini adalah link serat mode tunggal berjaringan multi-segmen yang berdedikasi, tidak ada perubahan sama sekali karena hanya L2 saja - oh dan saya harap itu bukan tautan 1Mbps, bukan dengan uang biayanya :)

— Chopper3

1

jika Anda menjembatani ke LAN Anda, yaitu tidak ada perutean di mana pun, maka siaran jaringan akan menyia-nyiakan kapasitas tautan, benar untuk 1gb itu akan menjadi sebagian kecil, tetapi layanan jaringan yang salah dapat meratakan tautan. Saya kira jembatan ini di luar kendali Anda. Sakelar ini mungkin kelebihan beban, atau menimbulkan latensi yang sangat tinggi. Latensi tinggi berarti bandwidth rendah.

— The Unix Janitor

@ user37899 - latensi tinggi tidak harus berarti bandwidth rendah, tetapi membutuhkan penyetelan ... tetap - berapa banyak latensi yang dapat Anda dapatkan dalam 200 mil - jika semuanya baik-baik saja - tidak ada yang lebih dari 3-10 ms. siaran arp [atau lainnya] di tautan gigabit mungkin sangat kecil dari keseluruhan kapasitas yang tersedia.

— pQd

1

Jika Anda memiliki siaran jaringan yang terjadi pada tingkat seperti itu untuk mempengaruhi kinerja tautan, maka saya curiga Anda akan memiliki masalah kinerja internal jauh sebelum saluran baru ini masuk dan akan memperhatikan sebanyak itu.

— joeqwerty

@ pQd saya sebenarnya berbicara tentang badai penyiaran.

— The Unix Janitor

0

RFC 2544 atau Y.156sam

Ini adalah tes jaringan yang dilakukan untuk membuktikan SLA oleh operator. IPERF dan sejenisnya bukan metode uji jaringan yang dapat diverifikasi.

— Ansel Gaddy
sumber