ปารีส → แฟรงก์เฟิร์ต · ~12 ms
เส้นทางที่ไม่มีใครเรียกว่าช้า
ห่างจากแบ็กโบนยุโรปเพียงหนึ่งฮอป
“ประเทศเดียว” จะทำให้คุณเสียอะไรก็ต่อเมื่อประเทศนั้นอยู่ไกล แต่มันไม่ได้อยู่ไกล — และหน้านี้คือการคำนวณ ไม่ใช่คำรับรอง
- บูคาเรสต์
- 12 ms
- แฟรงก์เฟิร์ต
- 35 ms
- อัมสเตอร์ดัม
- 42 ms
- วิธีการ
- ค่ามัธยฐาน 30 วัน
วัดผลแล้ว
สิบสองเมือง เรียงตามระยะทาง
เรียงลำดับแทนที่จะจัดกลุ่มตามภูมิภาค คุณจะหยุดอ่านทันทีที่ผ่านเมืองของคุณเองไปแล้ว
- บูคาเรสต์ 12ms
- เคียฟ 21ms
- วอร์ซอ 29ms
- เวียนนา 33ms
- แฟรงก์เฟิร์ต 35ms
- อิสตันบูล 38ms
- อัมสเตอร์ดัม 42ms
- Milan 45ms
- ลอนดอน 48ms
- สตอกโฮล์ม 52ms
- ดูไบ 92ms
- นิวยอร์ก 118ms
เซลล์ที่ไฮไลต์คือค่าต่ำกว่า 50 ms — ช่วงที่ SSH เดสก์ท็อประยะไกล และงานเชิงโต้ตอบให้ความรู้สึกเหมือนใช้งานในเครื่องท้องถิ่น ทุกเมืองในยุโรปในรายการนี้อยู่ในช่วงดังกล่าว ยกเว้นสตอกโฮล์มที่พลาดไปสองหน่วย
เพื่อการเปรียบเทียบ
35 มิลลิวินาทีไม่ใช่การประนีประนอม
ตัวเลขจะมีความหมายก็ต่อเมื่อนำไปเทียบกับตัวเลขที่คุณรู้จักอยู่แล้ว ต่อไปนี้คือเส้นทางสามเส้นที่ไม่มีใครเรียกว่าช้า และตำแหน่งของเราท่ามกลางเส้นทางเหล่านั้น
Chișinău → Frankfurt · ~35 ms
ของเรา สามเท่าของตัวเลขนั้น และยังต่ำกว่าเกณฑ์ที่มนุษย์จะสังเกตได้
ลอนดอน → นิวยอร์ก · ~75 ms
ผ่านการใช้งานจากทุกโต๊ะเทรดในย่านการเงินลอนดอนโดยไม่มีข้อร้องเรียน
แฟรงก์เฟิร์ต → สิงคโปร์ · ~160 ms
จุดที่งานเชิงโต้ตอบเริ่มสะดุดจริง ๆ
วิธีการวัดผล
ตัวเลขความหน่วงที่ไม่มีวิธีการวัดกำกับเป็นเพียงคำคุณศัพท์
ใครก็เผยแพร่ตัวเลขที่ดูดีได้ สิ่งที่ทำให้น่าอ่านคือการรู้ว่ามันถูกผลิตขึ้นมาอย่างไร — และสามารถผลิตซ้ำได้ด้วยตัวเอง
ICMP จาก edge ของเรา ไม่ใช่จากเครือข่ายตรวจสอบภายนอก
วัดจากเราเตอร์เดียวกับที่รับส่งทราฟฟิกจริง เครือข่ายตรวจวัดจากบุคคลที่สามตั้งอยู่ในดาต้าเซ็นเตอร์ที่มี peering ดีกว่าลูกค้าที่อ้างว่าเป็นตัวแทน
ค่ามัธยฐานตลอด 30 วัน ไม่ใช่ผลลัพธ์ที่ดีที่สุดเพียงครั้งเดียว
แพ็กเก็ตเดียวตอนตีสามไม่ได้พิสูจน์อะไร ตัวเลขที่แสดงคือค่ามัธยฐานจากการสุ่มตัวอย่างต่อเนื่อง ดังนั้นคืนที่สภาพเครือข่ายดีเป็นพิเศษจึงไม่ทำให้ตัวเลขดูดีเกินจริง
ถึงตัวเมือง ไม่ใช่ถึงจุด peering ที่ใกล้ที่สุด
เป้าหมายคือโฮสต์ที่เป็นที่รู้จักในแต่ละเขตเมืองใหญ่ ไม่ใช่ edge router ของ exchange ที่อยู่ใกล้เราที่สุด
และคุณสามารถทำซ้ำได้
เป้าหมายทุกจุดเปิดเผยต่อสาธารณะ และ looking glass รันคำสั่งชุดเดียวกันจากฝั่งเรา หากตัวเลขของคุณไม่ตรงกับของเรา เราอยากทราบ
ก่อนสั่งซื้อ
สามคำถามจากตัวเลขเหล่านี้
หากผลการวัดของคุณไม่ตรงกับหน้านี้ โปรดแจ้งฝ่ายสนับสนุน — เรายินดีแก้ไขตัวเลขมากกว่าปกป้องมัน
เปิด looking glassผู้ใช้ของฉันอยู่ในทวีปอเมริกา วิธีนี้ใช้ได้จริงหรือไม่
สำหรับเว็บไซต์ที่มี CDN อยู่ด้านหน้า แทบไม่มีผลเลย — เวลาแฝงจากต้นทางจะไม่มีความหมายอีกต่อไปเมื่อทรัพยากรถูกแคชไว้ที่ edge สำหรับบริการเชิงโต้ตอบที่มีผู้เล่นหรือนักเทรดอยู่ในนิวยอร์ก 118 ms คือของจริง และคุณควรสัมผัสมันก่อนตัดสินใจ ขอทดลองใช้จากฝ่ายสนับสนุน แล้ววัดผลด้วยตัวเอง
การกรอง DDoS ทำให้เกิดเวลาแฝงเพิ่มขึ้นหรือไม่
ต่ำกว่าหนึ่งมิลลิวินาทีในสภาวะปกติ — การกรองอยู่ต้นทางและอยู่บนเส้นทางโดยตรง ไม่ใช่การเบี่ยงผ่านศูนย์ scrubbing ที่อื่น ในระหว่างถูกโจมตีจริง คุณอาจเห็นค่าที่สูงขึ้นเล็กน้อย ซึ่งเป็นข้อแลกเปลี่ยนที่ทางเลือกอื่นทุกแบบก็ต้องยอมรับเช่นกัน เพียงแต่มักไม่บอกตรงๆ
ทำไมอิสตันบูลจึงช้ากว่าแฟรงก์เฟิร์ต
เพราะภูมิศาสตร์ไม่ใช่โทโพโลยี ปัจจุบันการรับส่งข้อมูลไปอิสตันบูลผ่านทรานซิตทางบูคาเรสต์และโซเฟีย แทนที่จะข้ามทะเลดำ ซึ่งเพิ่มระยะทางที่แผนที่ไม่ได้แสดง ผู้ให้บริการทรานซิตรายที่สามน่าจะช่วยให้ดีขึ้น และเราจะเผยแพร่ตัวเลขใหม่เมื่อเกิดขึ้นจริง แทนที่จะปล่อยตัวเลขเก่าไว้เฉยๆ