สภาพทางภูมิศาสตร์มีผลต่อความหน่วงของเครือข่ายอย่างไร


20

ฉันมีตัวเลือกในการโฮสต์ฐานข้อมูล / เว็บเซิร์ฟเวอร์ของเราที่ บริษัท โฮสติ้งที่มีการจัดการใน East Coast (US) หรือหนึ่งใน West Coast (US) บริษัท ของเราตั้งอยู่ที่นิวยอร์กซิตี้และผู้ให้บริการโฮสติ้งทั้งคู่ให้กล่อง T1 ของเราโดยเฉพาะ

ประสิทธิภาพการทำงานที่ได้รับผลกระทบเท่าไร (สมมติว่ามีปัจจัยอื่น ๆ ที่เท่ากันทั้งหมด) ฉันจะใช้เวลาในการแฝงเครือข่ายถ้าฉันไปกับหนึ่งในชายฝั่งตะวันตกเมื่อเทียบกับหนึ่งในชายฝั่งตะวันออก? ฉันไม่แน่ใจว่าภูมิศาสตร์มีผลต่อความเร็วอินเทอร์เน็ตอย่างไรเมื่อตัวเลขและระยะทางมีขนาดใหญ่มาก (T1 ขึ้นไปและหลายพันไมล์)

ขอบคุณ!


โอ้ฉันอิจฉาตำแหน่งของคุณอย่างไร เรามีลูกค้าในฟิลิปปินส์ที่ใช้งาน ISDN เป็นลิงก์เดียวสำหรับการรับส่งข้อมูลเครือข่ายทั้งหมด คุณต้องการที่จะพูดคุยแฝงพยายาม 700ms ระหว่างนั้นและเรา (ในออสเตรเลีย) เมื่อไม่มีการจราจรในบรรทัด :(
Mark Henderson

คำตอบ:


10

มีความล่าช้าในระยะทางและสิ่งอื่น ๆ ที่เท่าเทียมกัน (ประสิทธิภาพการกำหนดเส้นทางการดำเนินการค่าใช้จ่ายความแออัด ฯลฯ ) ไซต์บนชายฝั่งตะวันตกที่เข้าถึงโดยโฮสต์บนชายฝั่งตะวันออกจะใช้เวลานานกว่าถ้าไซต์นั้นอยู่ทางตะวันออก ชายฝั่ง แต่เรากำลังพูดถึงมิลลิวินาทีที่นี่


ลิงก์ลง .......
Pacerier

11

สิ่งอื่น ๆ ที่เท่ากันคุณจะมีเวลาแฝงเพิ่มอีก 44 มิลลิวินาทีเนื่องจากความเร็วแสง ให้หรือใช้เวลา 1/20 วินาทีในแต่ละแพ็คเก็ตไปกลับ ไม่มากนักสำหรับการใช้งานเว็บทั่วไป พอสำหรับช่วง ssh มีความสำคัญหากคุณเข้าถึงฐานข้อมูลโดยตรงด้วยธุรกรรมติดต่อกันจำนวนมาก

ฉันไม่สนใจเวลาแฝงเพิ่มเติมที่เกิดจากเราเตอร์ / ผู้ทำซ้ำเพิ่มเติมซึ่งอาจสูงกว่ามาก ฉันสันนิษฐานว่าระยะทาง 4400 กม. และความเร็วแสงเป็นเส้นใย 200000 กม. / วินาที


1ms ต่อ 100km นั้นถูกต้องหากไม่มีเราเตอร์อยู่ระหว่างนั้น ไฟเบอร์ทวนคำไม่เพิ่มเวลาแฝงเมื่อข้อเสนอของคุณดี
Ryaner

@Ryaner, คุณหมายถึงอะไรโดย ~ " Fibre Repeater มีเวลาแฝงเป็นศูนย์ " เป็นไปได้อย่างไร?
Pacerier

lightwaveonline.com/articles/print/volume-29/issue-6/feature/ ......ครอบคลุมรายละเอียดต่าง ๆ ได้เป็นอย่างดี TLDR ซึ่งเป็นผู้ทำซ้ำการฟื้นฟูแบบออปติคัลจะเพิ่มเวลาในการตอบสนอง แต่โดยทั่วไปแล้วจะเป็นศูนย์ในแง่จริง คุณจะเห็นเวลาแฝงที่เพิ่มขึ้นโดย DCM ที่ปลายทั้งสองและเราเตอร์จุดสิ้นสุดของคุณ
Ryaner

5

เรามีลูกค้าที่ใช้เวลาพอสมควรในการไปรอบ ๆ และเกี่ยวข้องกับสิ่งนี้ เดิมทีพวกเขาโฮสต์ที่นิวยอร์กและพนักงานส่วนใหญ่ตั้งอยู่ในเขตบอสตัน พวกเขาย้ายเซิร์ฟเวอร์ไปยังโรงงานของเราซึ่งตั้งอยู่ในเดนเวอร์ประมาณสองในสามของเส้นทางทั่วประเทศ

เมื่อพวกเขาย้ายพวกเขาเริ่มนำปัญหาประสิทธิภาพจากลิงค์ Comcast ในสำนักงานที่บ้าน พวกเขาเคยมีเวลาแฝง <10ms และมันสูงถึง 80-ish ms พวกเขาสังเกตเห็นประสิทธิภาพการทำงานที่ช้าลงถึงไซต์ของพวกเขา แต่กล่าวว่า "บางทีเราอาจจะต้องทนกับการเปลี่ยนจากความเร็วที่เร็วอย่างเห็นได้ชัดไปจนถึงความเร็วมรรตัย" พวกเขาดูเหมือนจะตระหนักว่ามีข้อ จำกัด เนื่องจากสภาพทางภูมิศาสตร์และผู้ใช้ของพวกเขาบนชายฝั่งตะวันตกจะได้รับประสิทธิภาพที่ดีขึ้น

เรากลับไปมาสองสามครั้ง หลังจากประมาณ 6 เดือนเราเปลี่ยนไปใช้ ISP ต้นน้ำหลักอื่นด้วยเหตุผลที่ไม่เกี่ยวข้องกับลูกค้ารายนี้ (การกำหนดราคาที่ดีกว่าแบนด์วิดธ์ที่มากขึ้นไม่พอใจกับจำนวนหน้าต่างการบำรุงรักษาของผู้ให้บริการรายอื่น) และผู้ให้บริการรายใหม่ เวลาแฝงเฉลี่ยสำหรับลูกค้ารายนี้ ณ จุดนี้ความกังวลด้านประสิทธิภาพดูเหมือนว่าจะหายไปแล้ว

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

ลองใช้ "mtr" เพื่อแสดงข้อมูลเกี่ยวกับเวลาแฝงและการสูญหายของแพ็กเก็ตกับรีโมตต่าง ๆ ยกเว้นว่าคุณเข้าใจเส้นทาง "เส้นทางที่ช้า" อย่างสมบูรณ์ไม่ต้องสนใจสิ่งใดนอกจากการกระโดดครั้งสุดท้ายที่แสดงรายการเอาท์พุทนั้น Van Jacobson กล่าวว่ามนุษย์สังเกตว่าเวลาแฝงเริ่มต้นที่ 400ms แต่ทราบว่าการเชื่อมต่อจำนวนมากต้องการการแลกเปลี่ยนไปมาหลายครั้งดังนั้นเวลาแฝง 100ms สามารถเพิ่มได้อย่างรวดเร็วถึงหนึ่งวินาที ...

จากประสบการณ์ของฉันความล่าช้า 250ms เริ่มรู้สึกว่าการเชื่อมต่อช้าลงอย่างเห็นได้ชัด 10ms หรือดีกว่ารู้สึกเหมือนการเชื่อมต่อที่เห็นได้ชัด มันขึ้นอยู่กับสิ่งที่คุณทำ

ฌอน


เดนเวอร์หมายถึง CO?
Pacerier

Btw "มนุษย์สังเกตความล่าช้าเริ่มต้นที่ 400ms" เป็นเท็จอย่างโจ๋งครึ่ม พูดคุยกับนักเล่นเกมใด ๆ และคุณจะเห็นว่ามีการแฝง 65ms (ขึ้นไป) เป็นที่ยอมรับไม่ได้อย่างสมบูรณ์
Pacerier

3

แพ็คเก็ตเดินทางลงลวดที่ใกล้พอกับความเร็วของแสงที่เวลาการส่งข้อมูลดิบจะเล็กน้อยเมื่อเทียบกับปัจจัยอื่น ๆ สิ่งที่สำคัญคือประสิทธิภาพของการกำหนดเส้นทางและอุปกรณ์การกำหนดเส้นทางที่รวดเร็วสามารถทำการกำหนดเส้นทางได้ แต่น่าเสียดายที่ไม่สามารถกำหนดได้อย่างหมดจดตามระยะทางภูมิศาสตร์ มีความสัมพันธ์ที่แน่นแฟ้นระหว่างระยะทางและเวลาแฝง แต่ก็ไม่มีกฎที่ยากและรวดเร็วที่ฉันรู้


อย่างไรก็ตามมีการพิจารณาประสิทธิภาพของเส้นทางหรือไม่ มีการทดสอบบางอย่างที่ฉันสามารถเรียกใช้บนเซิร์ฟเวอร์สองเครื่องเพื่อดูสิ่งนั้นและหมายเลขนั้นหมายถึงอะไร
neezer

2
แพ็คเก็ตเดินทางอย่างดีที่สุด 0.66 (ออปติคัล) และ ~ .55 (ทองแดง) คูณความเร็วของแสง
โนอาห์แคมป์เบลล์

@Noah - ดีกว่าเหรอ?
EBGreen

ดีกว่าความเร็วของแสง? ไม่ความเร็วของแสงประมาณครึ่งหนึ่ง
โนอาห์แคมป์เบลล์

ฉันหมายถึงคือการแก้ไขคำอธิบายที่ดีกว่าของฉัน
EBGreen

3

จำนวนฮ็อพระหว่างจุด A และจุด B จะแนะนำเวลาแฝง นับจำนวนฮ็อพเนื่องจากเป็นตัวบ่งชี้ที่ดีที่สุดของคุณ

คำเตือนเล็กน้อย วิธีการประเมินเส้นทางเครือข่ายไม่สอดคล้องกับวิธีการที่แพ็คเก็ตจริงจะไหล ICMP อาจถูกกำหนดเส้นทางและกำหนด QoS ที่แตกต่างกัน นอกจากนี้ traceroute ยังมีลักษณะในทิศทางเดียวเช่นต้นทางไปยังปลายทาง นี่คือเทคนิคที่มีประโยชน์บางอย่าง

สำหรับการtracerouteลองใช้-I, -Uหรือ-Tเพื่อดูว่าเส้นทางที่แตกต่างกันไป นอกจากนี้ยังดูหรือ -t 16 traceroute-t 8

ปิงมีประโยชน์จริง ๆ ping -Rจะแสดงเส้นทางที่ใช้ในการส่งคืน! หากมันแตกต่างจากเส้นทางที่ออกไปจากนั้นดูว่ามันกำลังจะไปไหน ปิง


2

ฉันคิดว่าสภาพทางภูมิศาสตร์มีส่วนเกี่ยวข้องกับเวลาในการส่งแพ็กเก็ตนับตั้งแต่ที่คุณไปไกลยิ่งคุณกระโดดมากเท่าไหร่คุณก็ยิ่งมีแนวโน้มที่จะกระทบกับเวลาแฝงโดยรวมมากขึ้นเท่านั้น หากลูกค้าของคุณจะขึ้นอยู่กับชายฝั่งตะวันตกส่วนใหญ่ฉันจะไปที่โฮสติ้งฝั่งตะวันตก ... สิ่งเดียวกันบนชายฝั่งตะวันออก หากลูกค้าของคุณจะมาจากทั่วสหรัฐอเมริกาหรือโลก ... จากนั้นคุณจะต้องตัดสินใจอย่างหนักว่าฝ่ายใดจะได้รับความล่าช้าน้อยลง

ในกรณีของเราเราอยู่ในเครือข่ายของเรา (อินทราเน็ตขนาดใหญ่) และสามารถให้เราเตอร์ของเราตัดสินใจบนพื้นฐานของ OSPF ทั่วทั้งรัฐ :) แต่น่าเสียดายที่สิ่งที่อยู่นอกเครือข่ายของเราขึ้นอยู่กับรูปแบบ ISP ของเราเป็นหลัก


เครื่องมือที่ยอดเยี่ยมที่คุณสามารถใช้คือ MTR เพื่อไม่เพียง แต่ค้นหาเวลาแฝง แต่การสูญหายของแพ็กเก็ตข้อมูลเส้นทางการกระวนกระวายใจ ฯลฯ ฉันได้โพสต์เกี่ยวกับข้อมูลที่ให้ไว้ที่นี่: serverfault.com/questions/21048/…
l0c0b0x
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.