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.
'Đừ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.
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ó.
Hai câu hỏi hay bị gộp làm một — đọc mỗi lần bao nhiêu byte, và có cần căn chỉnh không — hoá ra là hai câu chuyện khác hẳn. Cái giá của một thao tác I/O nằm ở chính thao tác đó (~35 µs cố định), không ở số byte, nên khối dưới 16 KB là tiền vứt đi. Còn O_DIRECT thì căn chỉnh sai không chậm mà trả EINVAL — và ngưỡng là 512 hay 4096 tuỳ phần cứng, một lớp lỗi chỉ lộ khi đổi ổ.
Cùng máy, cùng phần mềm, chỉ đổi đường truyền bằng tc netem. Độ trễ một mình lấy đi 69 lần thông lượng vì TCP phải chờ ACK sau mỗi cửa sổ. Rồi mất một phần nghìn số gói làm mọi thứ chậm 40 lần — vì CUBIC cắt đôi cửa sổ mỗi lần mất gói và không kịp lớn lại. Câu 'chỉ mất có 1% thôi' trong báo cáo sự cố nguy hiểm hơn nó nghe.