sendfile gộp cả file 512 MB vào ĐÚNG 1 lời gọi thay vì 16.384 read+write. Nhưng trên loopback cache ấm, tốc độ thô của nó còn thua read+write đệm 64K — và tôi suýt kết luận nó vô dụng. Lỗi nằm ở chỗ tôi đo thông lượng, trong khi sendfile thắng ở CPU/syscall. Đo thật.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.
Một tiến trình zombie có RSS ~0 KB, đo bộ nhớ thì tưởng vô hại. Nhưng nó giữ một slot PID, và PID là hữu hạn — đủ zombie thì cạn PID, fork() thất bại khắp máy dù RAM trống mênh mông. Tôi đã đo nhầm tài nguyên. Đo thật, kèm cái bẫy PID 1 trong container.
Cấu trúc kiểm tra thành viên phải chính xác 100%? Tôi đo thử: bloom filter đổi ~0,82% dương tính giả (khớp công thức đến hai chữ số) lấy RAM ít hơn 26 lần và query nhanh 3,3 lần. Điều tài tình: nó không bao giờ sai về việc vắng — nói 'không có' là chắc chắn không có.
Một tra cứu nguội đi ba vòng — root, TLD, thẩm quyền, mỗi vòng một khứ hồi (~75ms). Nhưng lần thứ hai 0 vòng, và một tên khác cùng đuôi chỉ 2 vòng vì chuỗi ủy quyền đã đệm. Đó là lý do root/TLD toàn cầu hầu như rảnh rỗi. Đo thật bằng cây DNS ba tầng tự dựng — kèm một bug gắn nhãn suýt qua mặt tôi.
Ghim CPU vào một nhân nghe hợp lý: cache ấm, không bị dời, chạy nhanh hơn. Nhưng đo ra ghim không hơn tự do — máy rảnh, dưới tải, kể cả khi ép dời liên tục. Vì bộ lập lịch đã tự giữ cache ấm, và phần cứng chia sẻ cache khiến dời rẻ. Tôi đã đo cho một lợi ích đã có sẵn. Đo thật.