Span db.query nói một con số, pg_stat_statements nói một con số khác cho đúng truy vấn đó, và chúng lệch nhau gần chục lần. Không cái nào sai — chúng đo hai thứ khác nhau, và cái hiệu của chúng mới là con số quyết định việc tối ưu SQL của bạn có ích hay hoàn toàn vô nghĩa.
Bộ công cụ tự động đắt hơn tự viết span 2,45 lần và chỉ cho thêm đúng một thuộc tính. Nhìn bảng thì viết tay thắng rõ. Nhưng so chi phí là so sai chỗ: thứ phân biệt hai cách không phải nano-giây, mà là cái giá của một lần ai đó quên.
Máy chủ tự báo 0,673 ms, người dùng thật chờ 151,255 ms — nó mù 99,6% thời gian. Tôi đo khoảng cách đó khi thêm độ trễ mạng, và phát hiện kích thước phản hồi chỉ lộ ra khi có độ trễ (chênh 2,2% trên mạng nhanh thành 128% khi thêm 50 ms), còn keep-alive tiết kiệm đúng một vòng khứ hồi. Ba con số trong bảng là ba đại lượng khác nhau, không phải ba mức chính xác của một đại lượng.
Giám sát thụ động chỉ thấy lỗi khi có ai đó gặp lỗi. Tôi đo khoảng cách của nó so với kiểm tra tổng hợp: ban ngày hai cách ngang nhau, nhưng ban đêm — giờ không ai dùng — thụ động bỏ lọt hơn nửa số sự cố ngắn. Toàn bộ giá trị của synthetic check nằm ở đúng cái khoảng trống lưu lượng đó.
Lấy mẫu hồ sơ ngoài tiến trình ở 99 Hz gần như không tốn gì (−0,8%), nên bật được suốt ngày ở production; còn cProfile làm chương trình chậm gấp 2,06 lần và tự tạo sự cố hiệu năng. Nhưng bài học lớn nhất là con số tôi đoán sai về mã của chính mình — thời gian chạy không tỷ lệ với số dòng.
Tôi cộng cả ba lớp quan sát trên cùng một dịch vụ và đo tổng: −12,9% thông lượng, +19,3% CPU, +45,8% bộ nhớ. Nhưng phát hiện quan trọng hơn con số tổng là mô hình chi phí — chỉ số giữ trạng thái gộp nên KHÔNG tỷ lệ với lưu lượng (1.312 byte dù 20 nghìn hay 20 triệu yêu cầu), còn log và trace ghi từng sự kiện nên phình tuyến tính. Cùng lượng việc, trace tốn gấp 1.540 lần chỉ số.