Mở sê-ri quan sát: tôi dựng một sự cố thật (0,2% request đi qua nhánh chậm) rồi soi bằng cả metric, log, trace và đo giá từng lăng kính. p99 mù hoàn toàn vì sự cố nằm gọn trong phần đuôi nó cắt bỏ; trung bình chỉ nhích 12%; ba trụ cột không thay thế nhau — metric nói CÓ, log nói request NÀO, trace nói chậm Ở ĐÂU. Phân vị bạn theo dõi quyết định tỷ lệ sự cố nhỏ nhất bạn thấy được.
Chốt sê-ri 50 phần: mọi con số đáng nhớ, và bảy bài học về cách đo mà tôi học được bằng cách đo sai.
Ai cũng khuyên đổi bộ lập lịch I/O cho nhanh. Đo thật trên NVMe: none, mq-deadline, kyber cho cùng một dải IOPS và p99, thứ hạng còn đổi giữa các lần chạy — vì bài toán chúng sinh ra để giải đã biến mất cùng đĩa quay. Trong khi đó read_ahead_kb, cái nút gần như không ai chỉnh, tạo chênh lệch 10,7 lần. Bạn đang chỉnh chỗ sáng, không phải chỗ hỏng.
Phần 2 thấy đường ống cho hơn bốn mươi lần thông lượng trên một kết nối. Bài này tìm điểm dừng: đường ống 10.000 đạt 969.426 ops/s (47,9×), nhưng 100.000 chỉ còn 473.477 — một nửa, vì chi phí đệm ở hai phía vượt phần tiết kiệm round-trip. Bất ngờ hơn: MGET 100 khoá nhanh hơn đường ống 100 lệnh 45% dù cùng một lượt đi về, vì một lệnh phân tích một lần thay vì trăm lần. Và bộ đệm khách thường không có giới hạn (0 0 0).
Ba hệ tệp, cùng một máy, cùng một bộ phép đo. Lần chạy đầu tiên cho một tỷ lệ đẹp, dễ nhớ, dễ giật tít — và sai hoàn toàn: chạy lại ba lần thì hai dải trùm lên nhau. btrfs kém rõ ở fsync vì sao chép khi ghi, ext4 ổn định nhất nên vẫn là mặc định cho cơ sở dữ liệu, còn câu hỏi 'hệ tệp nào nhanh hơn' thì không có câu trả lời — phải hỏi nhanh hơn ở việc gì.
Sentinel cho chịu lỗi nhưng dữ liệu vẫn nằm một máy; Cluster chia ra nhiều máy và lấy đi vài thứ. Dựng cụm sáu nút rồi đo: khách tự tính CRC16 gọi thẳng đúng nút đạt 16.907 ops/s với 0 lần MOVED, còn khách 'ngây thơ' chỉ 10.390 ops/s vì 67% lệnh bị chuyển hướng. Nhưng mất mát lớn nhất không đo bằng ops/s: MGET, MSET, Lua, MULTI đều chết với CROSSSLOT khi khoá nằm khác slot. Cái Cluster lấy đi là khả năng diễn đạt.