Năm cách ghi cùng một dòng log trong Python, đo trên máy thật: khoảng cách 25 lần giữa print và logging, và khi bóc tách thì định dạng thời gian chỉ chiếm 17% — 94% chi phí biến vào bộ khung dựng LogRecord. Kèm hai phát hiện: lời gọi bị lọc bỏ rẻ tới 82 lần, nhưng chỉ khi bạn không dùng f-string.
fsync là chỗ trả tiền cho lời hứa của write. Tôi đo nó trên bốn đích đến (tmpfs, ext4 tắt/bật rào chắn, overlay container) và thấy khoảng cách nghìn lần; rồi cho thấy một đòn bẩy trong tay ứng dụng — dồn ghi trước khi fsync — kéo thông lượng lên 79 lần. Đây là cùng cơ chế commit theo nhóm mà mọi cơ sở dữ liệu đều dùng.
Tạo tệp rỗng trên ext4 tới khi No space left on device — mà dung lượng còn dư 71%. Thủ phạm là inode: ext4 chốt cứng số lượng lúc mkfs, hết inode là hết tệp bất kể còn bao nhiêu GB. Cộng thêm bảng đo chi phí stat theo tầng liên kết mềm, trần chuỗi đúng 40, và một sai lầm đo lường tôi tự vấp: stat không đi theo liên kết.
TLS 1.3 hay được mô tả là 'thêm một vòng khứ hồi'. Tôi đo cùng máy, cùng chương trình, chỉ khác cổng: bắt tay thêm 995 µs còn mỗi vòng sau đó chỉ thêm 18 µs. Và 995 µs ấy gần như toàn bộ là CPU — chữ ký RSA, không phải độ trễ mạng. Đó đổi hẳn cách bạn tối ưu HTTPS.
Ở chiều ghi, lời hứa 'đã xong' của nhân là lời hứa suông cho tới khi dữ liệu thật sự xuống đĩa. Đo thật: dd trả về tức thì trong khi 512 MB còn kẹt trong page cache 5–10 giây nữa — cúp điện lúc đó là mất sạch dù ứng dụng đã được báo thành công. Đây cũng là lý do đo tốc độ ghi bằng một lần ghi ngắn không fsync chỉ đo tốc độ của RAM, và luôn cho con số đẹp đến khó tin.
'Đừ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.