Một tra cứu nguội đi ba vòng — root, TLD, thẩm quyền, mỗi vòng một khứ hồi (~75ms). Nhưng lần thứ hai 0 vòng, và một tên khác cùng đuôi chỉ 2 vòng vì chuỗi ủy quyền đã đệm. Đó là lý do root/TLD toàn cầu hầu như rảnh rỗi. Đo thật bằng cây DNS ba tầng tự dựng — kèm một bug gắn nhãn suýt qua mặt tôi.
Bốn chặng gọi tuần tự tốn 261ms; song song hoá còn 63ms. Nhưng một chặng chậm +100ms đẩy tổng song song lên 172ms — bằng chặng chậm nhất, không phải tổng. Và lần đầu đo, mỗi chặng cõng thêm 40ms lạ mà thủ phạm là chính cái máy chủ tôi tự dựng kẹt Nagle. Bài cuối của sê-ri. Đo thật.
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.
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.
Nagle và delayed ACK, mỗi cái đều hợp lý khi đứng riêng, gặp nhau tạo một thế chờ chết: một vòng request/response kẹt đúng ~40ms, lặp đi lặp lại. Đo thật con số (43ms so với 0,04ms — chênh gần 900 lần), và vì sao bug này khét tiếng khó tái hiện.
Bên đóng kết nối trước phải nằm TIME_WAIT đúng 60 giây trên Linux, và tcp_fin_timeout (thứ ai cũng khuyên vặn) KHÔNG chỉnh được nó — vì nó điều khiển một trạng thái khác. Đo thật ai gánh TIME_WAIT, bao lâu, và vì sao nó đặt trần ~470 kết nối/giây tới mỗi đích.