Round-robin chia đều tăm tắp theo lượt, kể cả nhét 20 request cho backend chậm nhất. Least-connections thì chỉ đưa nó 2 request, dồn phần còn lại cho hai máy rảnh. 'Đều' không phải 'cân bằng' — và cái khác biệt đó quyết định 1/N người dùng của bạn có phải chờ máy ốm hay không. Đo thật bằng nginx.
Kích thước bể kết nối chính là mức song song của client: pool 1 buộc 30 request nối đuôi (2581ms), pool 30 cho chạy song song (146ms) — nhanh gấp 18 lần. Nhưng lợi ích chững hẳn ngay khi đụng sức của backend, và một bể quá cỡ chỉ tốn tài nguyên. Đo thật.
Cùng một bản ghi, protobuf nhỏ hơn JSON ~2 lần và mã hóa nhanh hơn 7 lần — không phải 'chục lần' như đồn, và gzip còn làm phình một payload nhỏ. Cái lợi thật của gRPC hóa ra không phải vài byte, mà là CPU ở quy mô lớn, hợp đồng lược đồ, và bốn kiểu gọi streaming. Đo thật.
Một khung WebSocket gửi 'hi' chỉ tốn 8 byte trên dây. Nhưng giữ 3000 kết nối mở ngốn 45,8 KB mỗi cái trên máy chủ Python — trong khi 3000 socket TCP trần chỉ 0,1 KB. Tôi định đổ tội cho bộ đệm nhân, rồi một phép đo đối chứng lật ngược: cái đắt là runtime, không phải kết nối. Đo thật.
Trang 40 tài nguyên nhỏ: qua 10 mbit là thời gian chững ~520ms, nhưng RTT kéo nó tăng tuyến tính. Một file 5MB thì ngược hẳn — gấp đôi băng thông là gần nửa thời gian. Cái nào là nút thắt hoàn toàn tùy hình dạng tải, và một câu châm ngôn nghe rất kêu chỉ đúng một nửa. Đo thật bằng netem.
Mất gói không kéo cái trung bình — nó dựng một vách đứng ~200ms ở cái đuôi p99, nơi 1% người dùng xui nhất đang chịu trận mà bảng theo dõi trung bình không hề thấy. Và tôi vào bài chắc mẩm jitter là thủ phạm chính, hóa ra sai. Đo thật bằng netem.