Một broker Kafka thật ra khởi động 2 giây, chiếm 290 MB — nhẹ hơn hẳn tiếng tăm của nó. Nhưng thứ khiến tôi dừng lại là một cái bẫy đo lường: công cụ dòng lệnh tốn 0,86 giây trong khi gửi tin thật chỉ mất 0,89 mili giây. Chênh nhau một nghìn lần, và rất nhiều người đo trúng cái sai.
Kafka hay bị gọi là hàng đợi tin nhắn, và cái tên đó đẻ ra phần lớn hiểu nhầm. Tôi đo đặc tính thật sự định nghĩa nó: đọc không xoá tin, ba nhóm cùng đọc đủ. Và 493.421 tin mỗi giây không đến từ 'mỗi tin nhanh' — bỏ gộp lô thì mỗi tin nhanh gấp 34 lần mà thông lượng sụp đổ.
Sáu mươi phần, mỗi phần một phép đo, gom lại thành một câu SQL chạy được và một bản tổng kết. Cả năm con số ấn tượng nhất, bốn lời khuyên phổ biến mà phép đo bác bỏ, và ba bài học về cách đo rút ra từ chính những lần tôi đo sai.
Nâng cấp phiên bản lớn là việc mỗi năm làm một lần nên chẳng ai thuộc. Tôi chạy pg_upgrade thật từ PostgreSQL 16 lên 17, đo từng bước — và tìm ra thứ nó mang theo đầy đủ lẫn thứ nó lặng lẽ để lại, đủ khiến máy chủ vừa nâng xong chậm bất thường vài giờ đầu.
Sau năm mươi ba phần đo từng cơ chế, phần này đo cách tìm ra chỗ nào đáng đo. Kết quả đầu tiên đã đủ giật mình: cách xếp hạng phổ biến nhất — theo thời gian mỗi lần — dẫn thẳng tới việc tối ưu nhầm truy vấn, bỏ qua đúng câu đang chiếm nhiều tài nguyên nhất.
Đo bảng PostgreSQL phình lên rồi ổn định: VACUUM thường thu hồi chỗ để tái dùng nhưng giữ nguyên kích thước tệp, VACUUM FULL viết lại toàn bảng và chặn mọi truy vấn, còn autovacuum chạy chậm 25 lần vì bị hãm tốc từ thời đĩa cứng quay. Kèm cách phân biệt bloat thật với trạng thái cân bằng bình thường.