Đọc tuần tự 6701 MB/s, ngẫu nhiên 295 MB/s. Tôi định giải thích bằng 'seek' — rồi nhớ ra đây là SSD, không có đầu đọc để seek. Tách biến: đọc tuần tự y hệt mà TẮT readahead thì sụp còn 134 MB/s, chậm 50 lần. Thủ phạm thật là readahead, không phải seek. Đo thật.
Một kết nối rảnh có peer chết âm thầm: TCP mặc định mất ~2 giờ 11 phút mới phát hiện. Đặt ba núm keepalive thì xuống đúng IDLE + CNT×INTVL giây — vài giây. Đo thật công thức, kèm một bug 'hai chữ timeout' suýt làm tôi kết luận keepalive không chạy.
Tưởng write() xong là dữ liệu đã an toàn trên đĩa? Tôi đo: write() chỉ copy vào page cache (RAM) rồi trả về ngay — nhanh 7 lần so với ép lên đĩa bằng fsync, nhưng dữ liệu chưa bền, mất điện trước write-back là mất sạch. 'Đã ghi' và 'đã bền' là hai chuyện khác nhau.
Đo SCHED_FIFO so tiến trình thường ra 50:50 sạch sẽ — nhưng mã trả về rtok=0 tố cáo lệnh đặt lịch RT đã thất bại, tôi đang đo hai tiến trình thường. Cấp quyền RT: FIFO đè còn 95:5 — và cái 5% không phải real-time lịch sự mà là van an toàn của nhân chặn ở 95% để bạn không treo máy.
write() không đưa dữ liệu xuống đĩa ngay. Tôi ghi 300MB không fsync và nhìn Dirty trong /proc/meminfo: nó ghim nguyên 300MB suốt 30 giây rồi mới về 0. Cửa sổ 30 giây đó — nếu mất điện là bay sạch — chính là lý do phải fsync. Đo thật, kèm một cái bẫy quan sát.
HTTP/3 trên QUIC được cho là bắt tay nhanh hơn và chịu mất gói tốt hơn HTTP/2. Tôi đo ra ngược lại: bắt tay 554ms so với 176ms. Nhưng cái sai không nằm ở giao thức — nó nằm ở việc tôi so một thư viện QUIC thuần Python với ngăn xếp TCP của nhân. Bài học lớn nhất cả sê-ri về việc công cụ đo có thể lừa chính người đo.