หลายคนใช้เวลาหลายชั่วโมงเปรียบเทียบจำนวน vCPU แล้วกลับวางเซิร์ฟเวอร์ผิดทวีป สำหรับทุกอย่างที่ต้องโต้ตอบ (เชลล์ API เกม หรือบอทที่คุยกับกระดานเทรด) ตำแหน่งมักสำคัญกว่าฮาร์ดแวร์ ข่าวดีคือความหน่วงส่วนใหญ่เป็นเรื่องฟิสิกส์ คุณจึงคาดการณ์และวัดได้ก่อนจ่ายเงิน
ฟิสิกส์ในบรรทัดเดียว
แสงในใยแก้วนำแสงเดินทางราว 200 กม. ต่อมิลลิวินาที สายเคเบิลไม่ได้วิ่งเป็นเส้นตรงและเราเตอร์ทุกตัวเพิ่มความหน่วงเล็กน้อย กฎที่เชื่อถือได้จึงเป็น ราว 1 ms ไป-กลับต่อระยะทางจริง 100 กม.
| เส้นทาง | เวลาไป-กลับโดยทั่วไป |
|---|---|
| ภายในเมืองเดียวกัน | 1–3 ms |
| แฟรงก์เฟิร์ต ↔ เฮลซิงกิ | 20–25 ms |
| ยุโรปกลาง ↔ ลอนดอน | 10–20 ms |
| ยุโรป ↔ ชายฝั่งตะวันออกของสหรัฐฯ | 80–100 ms |
| ยุโรป ↔ ชายฝั่งตะวันตกของสหรัฐฯ | 140–170 ms |
| ยุโรป ↔ สิงคโปร์ / โตเกียว | 160–250 ms |
ไม่มี CPU แรงแค่ไหนที่แก้เวลาไป-กลับ 200 ms ได้ หากผู้ใช้ของคุณอยู่ที่โตเกียว เซิร์ฟเวอร์ในเยอรมนีจะรู้สึกช้าไม่ว่าจะเร็วเพียงใด
“ใกล้” หมายถึงอะไรขึ้นกับงาน
เว็บไซต์หรือ API ใกล้ผู้ใช้ส่วนใหญ่ของคุณ CDN ซ่อนระยะทางของไฟล์สแตติกได้ แต่การตอบกลับ HTML ครั้งแรก การล็อกอิน การเรียก API และทุกอย่างที่เป็นไดนามิกยังต้องเดินทางไปถึงเซิร์ฟเวอร์ต้นทาง
บอทเทรด ใกล้เซิร์ฟเวอร์ API ของกระดานเทรด ไม่ใช่ใกล้คุณ คุณนั่งอยู่ที่ไหนไม่สำคัญ บอทคุยกับกระดานเทรดหลายร้อยครั้งต่อวัน สำหรับ arbitrage ทุก ๆ ไม่กี่มิลลิวินาทีมีความหมาย แต่สำหรับบอทที่ส่งคำสั่งไม่กี่ครั้งต่อวัน 30 ms ไม่ต่างอะไร อ่านเพิ่มเติมที่ VPS ความหน่วงต่ำสำหรับบอทเทรด
เอเจนต์ AI ที่เรียก API ของโมเดล ตำแหน่งแทบไม่มีผล โมเดลใช้เวลาหลายวินาทีกว่าจะตอบ เครือข่าย 30 ms เป็นแค่สัญญาณรบกวน เลือกตามราคาและความเป็นส่วนตัว
เซิร์ฟเวอร์เกม ใกล้ผู้เล่น ต่ำกว่า ~60 ms ก็เล่นได้ดีสำหรับเกมส่วนใหญ่ เกมยิงแข่งขันต้องการต่ำกว่านั้นมาก
เดสก์ท็อประยะไกลและ SSH ใกล้คุณ การพิมพ์ที่มีความหน่วง 150 ms เป็นความทรมาน
วัดด้วยตัวเอง
จากเครื่องของคุณเอง หรือจากเซิร์ฟเวอร์ใกล้ผู้ใช้ ตรวจเส้นทางไปยังตำแหน่งที่พิจารณา:
mtr -rwc 50 example.com
mtr แสดงทุกฮอปพร้อมอัตราแพ็กเก็ตหายและความหน่วง มีประโยชน์กว่าการ ping ครั้งเดียวมาก เพราะเผยให้เห็นว่าความหน่วงเพิ่มขึ้นตรงไหน
จาก VPS ให้วัดบริการที่คุณพึ่งพาจริง แยกตามขั้นตอน:
curl -o /dev/null -s -w 'dns %{time_namelookup}s connect %{time_connect}s tls %{time_appconnect}s total %{time_total}s\n' \
https://api.example.com/health
connect คือเวลาไป-กลับของเครือข่ายโดยประมาณหนึ่งรอบ tls เพิ่มขั้นตอน handshake และ total รวมเวลาประมวลผลของเซิร์ฟเวอร์เอง หาก connect เป็น 2 ms แต่ total เป็น 900 ms ปัญหาของคุณไม่ใช่ระยะทาง
EQVPS เหมาะกับใคร
เซิร์ฟเวอร์ของเราอยู่ใน เยอรมนีและฟินแลนด์ และคุณเลือกตำแหน่งได้ในทุกคำสั่งซื้อ ซึ่งครอบคลุมผู้ใช้ทั่วยุโรปได้ดี ตะวันออกกลางพอใช้ และกระดานเทรดกับ endpoint API ในยุโรปได้ดีมาก ฟินแลนด์ไกลจากยุโรปตะวันตกกว่าไม่กี่มิลลิวินาทีและใกล้ประเทศนอร์ดิกกับบอลติกมากกว่าเล็กน้อย สำหรับงานส่วนใหญ่ใช้ได้ทั้งสองแห่ง
พูดตามตรง: เราไม่มีตำแหน่งในเอเชียหรือทวีปอเมริกา หากผู้ใช้ของคุณอยู่ที่นั่น เซิร์ฟเวอร์ในยุโรปจะเพิ่ม 80–250 ms ในทุกการไป-กลับ และคุณควรโฮสต์ให้ใกล้พวกเขามากกว่านี้
ฉบับย่อ
- ตัดสินใจว่าเซิร์ฟเวอร์คุยกับอะไรมากที่สุด: ผู้ใช้ กระดานเทรด API หรือตัวคุณ
- วางเซิร์ฟเวอร์ไว้ใกล้ สิ่งนั้น โดยใช้การประมาณ ~1 ms ต่อ 100 กม.
- วัดด้วย
mtrและcurl -wแทนการเชื่อแผนที่ - อย่าจ่ายเงินซื้อ CPU ที่เร็วขึ้นเพื่อแก้ปัญหาระยะทาง
หากคุณกำลังเลือกระหว่างแพ็กเกจ NAT กับแพ็กเกจ IP เฉพาะสำหรับเครื่องเดียวกัน นั่นเป็นอีกคำถามหนึ่ง: นี่คือแบบทดสอบคำถามเดียว
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ