fork() không copy dữ liệu nhờ copy-on-write, ai cũng biết — nhưng nó vẫn sao bảng trang, và chi phí đó tỉ lệ với RSS của cha. Tôi đo fork/vfork/posix_spawn khi cha giữ tới 1 GB: fork lên 3.850 µs còn vfork/posix_spawn phẳng lì, và tắt THP làm fork chậm thêm 9,3 lần. Vì sao THP che gần hết chi phí, đo bằng con số.
Một con số đúng vẫn có thể chẳng giúp được gì. Hồ sơ phẳng bảo toàn bộ CPU nằm trong một hàm tiện ích gọi từ khắp nơi — biết tên mà không biết ai gọi. Tách cùng số liệu ấy theo ngăn xếp: nén ngốn 85%, và một hàm nen() hiện ra hai lần với hai tỷ lệ khác nhau tuỳ ai gọi nó.
Một quy trình nâng cấp không downtime, đo thật: dựng bản mới làm bản sao (đồng bộ 0,6 giây), đổi vai trò (0,12 giây), khách mất đúng một lệnh ghi và 0,03 giây gián đoạn. Nhưng khi thử đảo ngược — cho bản cũ làm bản sao của bản mới — bản 6.2 không đọc nổi định dạng RDB của 7.4, dbsize về 0. Đây là quyết định một chiều, và mọi kiểm tra phải xong trước bước không quay lại được.
Một vòng lặp mở-đóng kết nối tới cùng một đích cạn hết dải cổng phù du trong 22 giây, vì mỗi cổng bị giữ ở TIME_WAIT 60 giây — tiêu nhanh gấp ba lần được trả lại. Ngưỡng thật chỉ ~470 kết nối/giây, thấp hơn trực giác nhiều. Và một dòng mã tưởng như chữa được hoá ra chỉ thay RST vào FIN: một cái bẫy đo lường kinh điển.
JSON to hơn 50% khi chưa nén và chỉ 6% sau khi nén. Nhưng grep trên log chữ nhanh gấp 19 lần jq.
Ba hệ tệp, cùng một máy, cùng một bộ phép đo. Lần chạy đầu tiên cho một tỷ lệ đẹp, dễ nhớ, dễ giật tít — và sai hoàn toàn: chạy lại ba lần thì hai dải trùm lên nhau. btrfs kém rõ ở fsync vì sao chép khi ghi, ext4 ổn định nhất nên vẫn là mặc định cho cơ sở dữ liệu, còn câu hỏi 'hệ tệp nào nhanh hơn' thì không có câu trả lời — phải hỏi nhanh hơn ở việc gì.