ระเบียบวิธีสำหรับการทดสอบประสิทธิภาพการเชื่อมโยง WAN


11

เรามีคู่เชื่อมโยงอีเทอร์เน็ต 1Gbps ที่กำหนดเส้นทางใหม่ระหว่างสถานที่ห่างกันประมาณ 200 ไมล์ 'ลูกค้า' เป็นเครื่องที่ทรงพลังพอสมควร (HP DL380 G6, Dual E56xx Xeons, 48GB DDR3, R1 คู่ 300GB 10krpm ดิสก์ SAS, W2K8R2-x64) และ 'เซิร์ฟเวอร์' เป็นเครื่องที่ดีพอเช่นกัน (HP BL460c G6 คู่ E55xx Xeons, 72GB, R1 คู่ของ 146GB 10krpm ดิสก์ SAS, พอร์ตคู่ Emulex 4Gbps FC HBA ที่เชื่อมโยงกับ Cisco MDS9509s คู่แล้วลงบน HP EVA 8400 โดยเฉพาะกับ 128 x 450GB 15krpm FC ดิสก์, RHEL 5.3-x64)

การใช้ SFTP จากไคลเอนต์เราจะเห็นประมาณ 40Kbps ของปริมาณงานโดยใช้ไฟล์ขนาดใหญ่ (> 2GB) เราได้ทำการทดสอบเซิร์ฟเวอร์กับ 'เซิร์ฟเวอร์ในพื้นที่อื่น' และดูประมาณ 500Mbps ผ่านสวิตช์โลคัล (Cat 6509s) เราจะทำแบบเดียวกันกับฝั่งไคลเอ็นต์ แต่นั่นเป็นเวลาหนึ่งวันหรือมากกว่านั้น

คุณจะใช้วิธีการทดสอบแบบใดในการพิสูจน์ผู้ให้บริการลิงก์ว่าปัญหานั้นเกิดจากอะไร


ฉันต้องการทราบคำตอบสำหรับสิ่งนี้ เราได้รับ 100Mbit leased line ของเราติดตั้งในสัปดาห์หน้า :)
Tom O'Connor

ตามที่ผู้ใช้ 37899 พูด - ผลลัพธ์จะได้รับการชื่นชม
pQd

อัพเดทใด ๆ ฉันอยากรู้ว่าสิ่งนี้จะเปิดออก
Kyle Brandt

ฉันทุบตีผู้ให้บริการลิงค์ "ค่อนข้างแย่" (แดกดันพวกเขาเป็นส่วนหนึ่งขององค์กรเดียวกันกับที่ฉันทำงาน!) - พวกเขายังไม่กลับมาหาเรา
Chopper3

1
อาตกลงและถ้าคุณสามารถหาสาเหตุที่ฉันได้รับ 7 โหวตสำหรับserverfault.com/questions/134467/และ 1 สำหรับสิ่งนี้ฉันอยากจะรู้ ;-)
Kyle Brandt

คำตอบ:


10

การปรับช้าง:
สิ่งนี้อาจต้องมีการปรับแต่งอาจไม่ใช่ปัญหาที่นี่เนื่องจาก pQd พูดว่า ลิงค์ประเภทนี้รู้จักกันในชื่อ "Long, Fat Pipe" หรือ elephant (ดูRFC 1072 ) เนื่องจากนี่เป็นท่อ gigabit ที่มีไขมันซึ่งวิ่งผ่านระยะทาง (ระยะทางคือเวลา / เวลาแฝงจริง ๆ ในกรณีนี้) หน้าต่างรับ tcp ต้องมีขนาดใหญ่ (ดู TCP / IP Illustrated Volume 1, ส่วนต่อขยาย TCP สำหรับรูปภาพ)

หากต้องการทราบว่าหน้าต่างรับต้องเป็นอะไรคุณคำนวณผลิตภัณฑ์ความล่าช้าแบนด์วิดท์:

Bandwidth * Delay = Product

หากมีเวลาในการตอบสนอง 10 มิลลิวินาทีเครื่องคิดเลขนี้จะประมาณว่าคุณต้องการหน้าต่างรับประมาณ 1.2 MBytes เราสามารถทำการคำนวณด้วยสูตรข้างต้น:

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

ดังนั้นคุณอาจต้องการเรียกใช้การถ่ายโอนข้อมูลแพ็คเก็ตเพื่อดูว่าการปรับขนาดหน้าต่าง tcp (ส่วนขยาย TCP ที่อนุญาตให้มีหน้าต่างขนาดใหญ่กว่า) เกิดขึ้นถูกต้องหรือไม่หากคุณทราบว่าปัญหาใหญ่คืออะไร

Window Bound:
หากปัญหานี้เกิดขึ้นแสดงว่าคุณมีขนาดหน้าต่างที่ถูกผูกไว้โดยไม่มีการปรับขนาดฉันจะคาดหวังผลลัพธ์ต่อไปนี้หากไม่มีการปรับมาตราส่วนของหน้าต่างและมีความล่าช้าประมาณ 200ms โดยไม่คำนึงถึงขนาดของท่อ:

Throughput = Recieve Window/Round Trip Time

ดังนั้น:

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

เพื่อให้ได้ผลลัพธ์ที่คุณเห็นคุณเพียงแค่ต้องแก้ปัญหาความล่าช้าซึ่งจะเป็น:

RTT = RWIN/Throughput

ดังนั้น (สำหรับ 40 kBytes / s):

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

(โปรดตรวจสอบคณิตศาสตร์ของฉันและแน่นอนสิ่งเหล่านี้ไม่รวมค่าใช้จ่ายโปรโตคอล / ส่วนหัวทั้งหมด)


คุณรู้ว่าฉันรู้สึกผิดเล็กน้อยที่จะ 'แซง' คุณชั่วคราวในช่วงสัปดาห์ที่ผ่านมาและเหตุผลก็คือเพราะคำตอบของคุณดีแค่ไหน - และบูม! คุณยังใช้เชลล์ทำคณิตศาสตร์ของคุณไม่ใช่เครื่องคิดเลข Mac ขนาด 1.5 MB ฉันทำได้! :) ขอขอบคุณ.
Chopper3

1
คุณมีคำตอบที่ดีเช่นกันและฉันชอบที่ฉันมีใครบางคนที่ฉันใกล้ชิดในเกมช่วยเพิ่มเกมเล็กน้อย :-) ข้อความค้นหาด่วนของ google เตือนฉันว่าคุณได้ตอบคำถามของฉันด้วย: serverfault.com/questions/107263/ … . ฉันแค่ซาบซึ้งจริงๆผู้ใช้ที่พยายามทำให้ชุมชนนี้ 'เกิดขึ้น' แต่ขอบคุณสำหรับความสมบูรณ์!
Kyle Brandt

ฉันก็ไม่มีอะไรที่ฉันชอบมากไปกว่าการรู้ว่าเราได้ช่วยคนที่รู้สึกว่าตนเองมีปัญหาที่น่าผิดหวัง - นอกเหนือจากชีสแน่นอน ที่กล่าวว่าฉันเกลียดเมื่อเราได้รับคำถามที่ไม่ดีเช่นกันคุณได้ยินคำถามของฉันใน SO podcast 82 หรือไม่? รับเสื้อยืด SF ฟรีจากมันเช่นกัน!
Chopper3

ฉันฟังพอดคาสต์ส่วนใหญ่แล้ว แต่พลาดไปหนึ่งอันจะย้อนกลับไปดูมัน (อาจจะเป็นสุดสัปดาห์นี้)
Kyle Brandt

ขออภัยเกี่ยวกับ pQd นั้นฉันมักจะอ่านชื่อเล่นของคุณเป็น PDQ เช่นเดียวกับใน PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)
Kyle Brandt

6

40kbps อยู่ในระดับต่ำมาก [จนถึงจุดที่ฉันสงสัยว่าตัวแปลงสื่อที่ผิด / duplex ไม่ตรงกัน [แต่คุณมีกิกะบิตดังนั้นจึงไม่มีที่สำหรับครึ่งเพล็กซ์!] ฯลฯ ] จะต้องมีการสูญเสียแพ็คเก็ตหรือกระวนกระวายใจที่สูงมากที่เกี่ยวข้อง

iperf เป็นเครื่องมือแรกที่อยู่ในใจของฉันในการวัดปริมาณงานที่มี วิ่งไปด้านใดด้านหนึ่ง

iperf -s 

และอื่น ๆ :

iperf -t 60 -c 10.11.12.13

จากนั้นคุณสามารถสลับบทบาทไคลเอนต์ / เซิร์ฟเวอร์ใช้ -d สำหรับดูเพล็กซ์ ฯลฯ รัน mtr ระหว่างเครื่องทั้งสองก่อนเริ่มการทดสอบและดูว่าการสูญเสียเวลาแฝง / แพ็คเก็ตใดที่คุณมีบนลิงก์ที่ไม่ได้ใช้และวิธีเปลี่ยนในระหว่างการถ่ายโอนข้อมูล

คุณต้องการดู: กระวนกระวายใจขนาดเล็กมากและไม่มีการสูญเสียแพ็กเก็ตจนกว่าลิงก์จะอิ่มตัวที่ 90 เปอร์เซ็นต์ของความจุ

iperf สำหรับ* ระวังและชนะอ่านที่นี่และที่นี่เกี่ยวกับมัน

MTR สำหรับ ระวัง *และชนะ


เรารู้ว่าลิงค์นั้นประกอบไปด้วยลิงค์ 1000-base-zx 6 ลิงก์ดังนั้นมันจึงมีข้อผูกมัดที่แฝงอยู่ในสิ่งที่ทำซ้ำ แต่ถึงอย่างนั้นฉันก็ประหลาดใจเมื่อคุณรู้ว่ามันต่ำแค่ไหน ทางฉันลืมไปเลยว่ามันมีอยู่จริง!
Chopper3

กรุณาโพสต์ผลลัพธ์ของคุณ!
Unix Janitor

1

tracepath สามารถแสดงปัญหาการเราต์ระหว่างสองไซต์

iperf, ttcp และ bwping สามารถให้ข้อมูลที่เป็นประโยชน์แก่คุณได้

คุณรู้วิธีการจัดเตรียมลิงค์ 1GB นี้หรือไม่? คุณกำลังเชื่อมโยงหรือกำหนดเส้นทางผ่านลิงก์นี้หรือไม่ SLA ของคุณสำหรับลิงก์คืออะไร คุณสามารถสร้างโดยผู้ให้บริการลิงก์ของคุณหรือไม่

หากคุณได้รับเพียง 40kbs แสดงว่ามีปัญหาร้ายแรงคุณแน่ใจหรือไม่ว่าไม่ใช่ลิงก์ของ 1MB แทนที่จะเป็น 1GB / s คุณอาจจะพบว่าความเร็วของลิงค์ไม่ใช่สิ่งที่คุณคิด :-)


ขอบคุณสำหรับคำตอบของคุณมันเป็นลิงค์เชื่อมโยงโหมดเดี่ยวแบบหลายเซ็กเมนต์โดยเฉพาะไม่มีการปรับเปลี่ยนใด ๆ เลยเพราะมันเป็น L2 ไปตลอดทาง - โอ้และฉันหวังว่ามันจะไม่ใช่ลิงค์ 1Mbps ไม่ใช่เงินที่คุ้มค่า :)
Chopper3

1
หากการเชื่อมต่อไปยัง LAN ของคุณคือไม่มีการกำหนดเส้นทางใด ๆ การส่งสัญญาณเครือข่ายจะสูญเสียความสามารถในการเชื่อมโยงซึ่งเป็นจริงสำหรับ 1GB ซึ่งจะเป็นเพียงเล็กน้อย แต่บริการเครือข่ายที่ทำงานผิดปกติ ฉันคิดว่าสะพานเหล่านี้อยู่นอกเหนือการควบคุมของคุณ สวิตช์เหล่านี้อาจทำงานหนักเกินไปหรือเกิดความล่าช้าสูงมาก เวลาแฝงสูงหมายถึงแบนด์วิธต่ำ
Unix Janitor

@ user37899 - เวลาในการตอบสนองสูงไม่จำเป็นต้องใช้แบนด์วิดท์ต่ำ แต่ต้องการการปรับแต่ง ... อย่างไรก็ตาม - เวลาในการตอบสนองที่คุณสามารถรับได้ 200 ไมล์ - หากสิ่งต่าง ๆ ใช้ได้ - ไม่เกิน 3-10ms arp [หรืออื่น ๆ ] การออกอากาศที่ลิงค์กิกะบิตอาจเป็นเพียงส่วนเล็ก ๆ ของความจุทั้งหมดที่มี
pQd

1
หากคุณมีการออกอากาศเครือข่ายที่เกิดขึ้นในระดับที่มีผลต่อประสิทธิภาพของลิงก์ฉันก็สงสัยว่าคุณจะมีปัญหาเกี่ยวกับประสิทธิภาพภายในก่อนที่จะมีการขึ้นบรรทัดใหม่และจะสังเกตเห็นได้มาก
joeqwerty

@pQd ฉันกำลังพูดถึงพายุออกอากาศ
นักเลง Unix

0

RFC 2544 หรือY.156sam

เหล่านี้คือการทดสอบเครือข่ายที่ดำเนินการเพื่อพิสูจน์ SLA โดยผู้ให้บริการ IPERF และที่คล้ายกันไม่ได้เป็นวิธีการทดสอบเครือข่ายที่ตรวจสอบได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.