strace muốn nhìn phải dừng tiến trình rồi đọc thanh ghi từ bên ngoài — chậm 446 lần. eBPF nạp thẳng chương trình đo vào trong nhân, chạy tại chỗ. Kết quả: 2 lần chi phí, thấy cả máy trong một lần đo, và một cái đuôi 128–256 micro giây mà không trung bình hay phân vị nào bắt được.
Ghi log nằm trên đường đi của mọi yêu cầu. Tôi đo sáu cách ghi cùng một dòng: định dạng chuỗi tốn 0,052 µs, còn fsync mỗi dòng tốn 515,903 µs — chi phí không nằm ở chỗ ai cũng tối ưu (định dạng) mà ở mỗi lần dữ liệu *ra khỏi tiến trình*. Kèm cái bẫy đắt nhất: một log.debug đã tắt vẫn dựng chuỗi trước khi bị bỏ, tốn 62 lần so với truyền tham số rời.
Lấy giờ là thứ mọi log, mọi số liệu, mọi phép đo đều làm. Tôi đo chín cách và tìm ra chênh lệch 11 lần giữa hai cách gọi cùng một hàm (vDSO hay không), một biến thể COARSE rẻ 6 lần đổi lấy độ phân giải 1 ms, và một hàm — clock_getres — báo sai độ phân giải thật tới 24.000 lần. Kèm lỗi kinh điển: dùng REALTIME cho thời hạn.
'Đừng dùng /dev/random, nó sẽ chặn' là một trong những lời khuyên Linux được lặp nhiều nhất — và sai từ nhân 5.6. Tôi đo: /dev/random và /dev/urandom cho cùng 780 MB/s, entropy không tiêu hao, còn rand() nhanh gấp mười ở 16 byte nhưng CHẬM nhất ở 4 KB và không đoán nổi ai dùng nó cho bảo mật. Lập luận 'dùng RNG yếu cho nhanh' không còn cơ sở đo lường.
Mọi container bị dừng thường xuyên hơn bị lỗi. Tôi đo sáu cách đóng gói cùng một ứng dụng: cái dừng trong 113 ms trông đẹp nhất trên bảng điều khiển nhưng là cái duy nhất không chạy dọn dẹp. Dừng nhanh không phải dừng êm — chỉ số đúng là mã thoát 0 cộng bằng chứng trong log, và hai lỗi đóng gói khác nhau cho cùng một triệu chứng.
Zombie không phải lỗi của tiến trình con mà của cha không đọc mã thoát. Tôi đo: một vòng waitpid dọn sạch 200 con, còn fork không thu hồi thì cạn 5.000 PID trong 0,17 giây và mọi tiến trình trong container nhận EAGAIN — triệu chứng là 'không tạo được tiến trình' trong khi RAM và CPU vẫn bình thường, đúng chỗ người trực đi tìm sai hướng.