Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Đo truy vấn nhẹ ra 0,028ms rồi nhẩm 'app gọi vài chục nghìn lần một giây thoải mái'. Nhưng đó là khi tái dùng kết nối — mở kết nối mới mỗi lần chỉ còn 1499 tps, chậm 23 lần. Mỗi kết nối PostgreSQL là một tiến trình phải fork; chi phí mở đường lấn át chính truy vấn. Vì sao pool kết nối là lời giải, không phải tăng max_connections.
Tưởng mmap/malloc xong là có bộ nhớ dùng ngay, và đo chi phí fault chỉ cần chạm trang rồi chia số trang? Tôi đo: một minor fault ~368ns, nhưng rusage lộ ra chỉ 364 fault cho 30.000 trang vì huge page gom 512 trang mỗi fault — chia đều thành 58ns là sai gần 6 lần. Phải đếm số fault thật.
veth là sợi cáp ảo nối đúng hai vùng, cầu nối là switch ảo cho nhiều vùng — bộ khung của mạng Docker. Tôi dựng một chuỗi cáp để chứng minh nó không thể thành mạng, rồi ngã ngửa khi nó thông ngay: network namespace thừa kế ip_forward=1 của Docker chứ không phải 0 như máy Linux trần. Đo thật.
Tưởng tạo luồng gần như miễn phí, còn fork đắt gấp trăm lần vì phải nhân đôi cả bộ nhớ? Tôi đo: tạo+join một luồng rỗng mất ~47µs (không hề miễn phí), fork+waitpid ~82µs — fork chỉ 1,8 lần thread nhờ copy-on-write. Cả hai đều tốn hàng chục micro giây, và đó là lý do có thread pool.
Tưởng một cấu trúc chung với một khóa là đủ, hoặc càng nhiều shard càng tốt? Tôi đo: một khóa chung sụp từ 229 xuống 35,7 triệu op/s khi đông luồng, chia nhiều shard giúp throughput scale 3 lần — nhưng càng nhiều shard, tính tổng toàn cục càng đắt (65 nghìn shard mất 32,8µs). Sharding dời chi phí chứ không xóa.
Đọc mã nguồn cả ngày cũng không thấy tranh chấp: hai luồng, hai biến riêng, không đụng nhau. Vậy mà chậm ~3,7 lần chỉ vì hai biến tình cờ nằm chung một cache line. Nút thắt vô hình ở tầng mã nguồn, chỉ lộ khi nhìn xuống bố trí bộ nhớ. Đo thật, và cách săn nó.