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.
Đo thời gian trôi qua bằng giờ tường, tôi nhận về -1,000 giây — một khoảng thời gian âm, đoạn code chạy xong trước khi bắt đầu. Vì giờ tường nhảy lùi khi bị chỉnh (NTP, admin). Đo thời lượng phải dùng đồng hồ đơn điệu — CLOCK_MONOTONIC cho +0,000032s đúng đắn ngay cùng lúc đó.
Atomic fetch_add đúng là nhanh hơn mutex 2,8 lần khi một luồng. Nhưng một biến atomic chung scale ÂM: 627 tụt xuống 34 triệu/giây ở 10 luồng vì cache-line ping-pong, gần bằng mutex. Cách nhanh thật không phải khóa xịn hơn mà là không chia sẻ — đếm riêng nhanh gấp ~180 lần. Tôi đo.
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.
Unix socket mang tiếng 'socket' nhưng không hề chậm hơn pipe: 12597 so với 10791 MB/s vì AF_UNIX đi thẳng trong nhân, không qua mạng. Khác biệt thật là ngữ nghĩa — SOCK_STREAM gộp byte và báo EOF, SOCK_DGRAM giữ ranh giới gói và không có EOF, nên một vòng read() bê nguyên sang datagram sẽ treo vô tận.
Tưởng tạo luồng mỗi việc là ổn cho việc nhỏ, hoặc thread pool là kỹ thuật rườm rà thừa? Tôi đo: 20.000 việc nhỏ kiểu thread-per-task mất 989ms vì chi phí tạo luồng ~47µs lấn át việc thật, còn thread pool nhanh 125 lần với số worker quanh số lõi — quá nhiều worker lại chậm đi. Một chi phí nhỏ nhân số lần lớn thành nút thắt khổng lồ.