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.
Phân quyền PostgreSQL có bốn lớp, mỗi lớp chặn được một thứ khác nhau. Tôi đo từng lớp trên bảng nhân viên bốn dòng và tìm ra ba chỗ chúng không chặn — chỗ đáng nhớ nhất là một thông báo lỗi khẳng định sự tồn tại của đúng dòng mà chính sách đang cố giấu.
Ai cũng bảo gộp lô là 'đổi độ trễ lấy thông lượng'. Tôi đo thì thấy nó làm độ trễ giảm 1.567 lần, cùng lúc với thông lượng. Còn nén trên dữ liệu ngẫu nhiên lại cho ra tệp to hơn bản không nén — và đó chính là cái bẫy suýt khiến tôi kết luận ngược.
Bản sao lưu hàng đêm chỉ đưa bạn về nửa đêm hôm qua. Khôi phục theo thời điểm đưa bạn về một giây trước khi ai đó gõ nhầm — nhưng chỉ khi bạn đã chuẩn bị trước tai nạn. Tôi chạy đủ quy trình từ đầu đến cuối, và cho thấy đặt mốc sai thì nó im lặng đưa bạn về nhầm chỗ.
Sao lưu là việc ai cũng làm và ít ai đo. Tôi đo năm cách trên cùng một cơ sở dữ liệu, và chỉ ra bốn thứ mà cách phổ biến nhất không hề lấy — trong đó có mật khẩu của mọi tài khoản, thứ chỉ lộ ra khi bạn khôi phục và không ai vào được.
pg_stat_statements trả lời 'truy vấn nào tốn nhất'. Các khung nhìn pg_stat_* trả lời câu khác: bảng nào, chỉ mục nào, bộ đệm đang làm gì. Tôi đo chúng nói gì, ba chỗ chúng im lặng — gồm một sự cố xoá sạch mọi bộ đếm — và một dự đoán của tôi bị bác bỏ.