Người ta dành hàng giờ so sánh số vCPU rồi lại đặt máy chủ ở sai châu lục. Với mọi thứ mang tính tương tác (shell, API, game, bot nói chuyện với sàn giao dịch), vị trí thường quan trọng hơn phần cứng. Tin tốt là độ trễ chủ yếu là vật lý, nên bạn có thể dự đoán và đo nó trước khi trả tiền.
Vật lý trong một dòng
Ánh sáng trong cáp quang đi khoảng 200 km mỗi mili giây. Cáp không chạy thẳng và mỗi router lại cộng thêm một chút, nên quy tắc đáng tin là khoảng 1 ms khứ hồi cho mỗi 100 km khoảng cách thực tế.
| Tuyến | Khứ hồi điển hình |
|---|---|
| Trong cùng một thành phố | 1–3 ms |
| Frankfurt ↔ Helsinki | 20–25 ms |
| Trung Âu ↔ London | 10–20 ms |
| Châu Âu ↔ bờ đông nước Mỹ | 80–100 ms |
| Châu Âu ↔ bờ tây nước Mỹ | 140–170 ms |
| Châu Âu ↔ Singapore / Tokyo | 160–250 ms |
Không lượng CPU nào sửa được khứ hồi 200 ms. Nếu người dùng của bạn ở Tokyo, máy chủ ở Đức sẽ có cảm giác chậm dù nó nhanh đến đâu.
“Gần” nghĩa là gì tùy vào công việc
Website hoặc API. Gần phần lớn người dùng của bạn. CDN che giấu khoảng cách cho tệp tĩnh, nhưng phản hồi HTML đầu tiên, đăng nhập, lệnh gọi API và mọi thứ động vẫn phải đi về máy chủ gốc.
Bot giao dịch. Gần máy chủ API của sàn, không phải gần bạn. Bạn ngồi ở đâu không quan trọng; bot nói chuyện với sàn hàng trăm lần mỗi ngày. Với arbitrage, từng vài mili giây đều có giá trị; với bot chỉ đặt vài lệnh mỗi ngày, 30 ms chẳng tạo khác biệt gì. Xem thêm tại VPS độ trễ thấp cho bot giao dịch.
Agent AI gọi API mô hình. Vị trí gần như không quan trọng. Mô hình mất vài giây để trả lời; 30 ms mạng chỉ là nhiễu. Hãy chọn theo giá và quyền riêng tư.
Máy chủ game. Gần người chơi. Dưới ~60 ms là ổn với hầu hết game; game bắn súng thi đấu cần thấp hơn nhiều.
Máy tính từ xa và SSH. Gần bạn. Gõ phím với độ trễ 150 ms thật khổ sở.
Tự đo lấy
Từ máy của bạn, hoặc từ một máy chủ gần người dùng, hãy kiểm tra đường đi tới vị trí dự kiến:
mtr -rwc 50 example.com
mtr hiển thị từng chặng kèm tỷ lệ mất gói và độ trễ: hữu ích hơn nhiều so với một lệnh ping đơn lẻ, vì nó cho thấy độ trễ được cộng thêm ở đâu.
Từ VPS, hãy đo dịch vụ mà bạn thực sự phụ thuộc, tách theo từng giai đoạn:
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 gần bằng một lượt khứ hồi mạng, tls cộng thêm bước bắt tay, còn total gồm cả thời gian xử lý của máy chủ. Nếu connect là 2 ms mà total là 900 ms, vấn đề của bạn không phải khoảng cách.
EQVPS phù hợp ở đâu
Máy chủ của chúng tôi đặt ở Đức và Phần Lan, và bạn chọn vị trí cho mỗi đơn hàng. Điều đó phủ tốt người dùng khắp châu Âu, khá ổn với Trung Đông, và rất tốt với các sàn cũng như endpoint API châu Âu. Phần Lan xa Tây Âu hơn vài mili giây và gần các nước Bắc Âu, Baltic hơn một chút; với hầu hết tác vụ, cả hai đều dùng tốt.
Nói thật: chúng tôi không có vị trí ở châu Á hay châu Mỹ. Nếu người dùng của bạn ở đó, máy chủ ở châu Âu sẽ cộng thêm 80–250 ms cho mỗi lượt khứ hồi, và bạn nên lưu trữ gần họ hơn.
Phiên bản ngắn gọn
- Xác định máy chủ trò chuyện nhiều nhất với ai: người dùng, một sàn, một API, hay chính bạn.
- Đặt nó gần đối tượng đó, ước tính ~1 ms cho mỗi 100 km.
- Đo bằng
mtrvàcurl -wthay vì tin vào bản đồ. - Đừng trả tiền cho CPU nhanh hơn để sửa một vấn đề về khoảng cách.
Nếu bạn đang phân vân giữa gói NAT và gói IP riêng cho cùng một máy, đó là một câu hỏi khác: đây là bài kiểm tra chỉ với một câu hỏi.
Bình luận
Chưa có bình luận nào. Hãy là người đầu tiên.