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.
Một lần revalidate với ETag khớp biến response 56 KB thành 152 byte — tiết kiệm hơn 99% băng thông. Nhưng một ETag đổi mỗi lần (bug rất phổ biến) biến mọi 304 thành 200, đốt lại toàn bộ băng thông mà trang vẫn chạy đúng, test vẫn xanh, không lỗi nào báo. Đo thật bằng byte trên dây.
Tưởng kiểm null rồi khóa rồi kiểm lại là đủ, và DCL chỉ là mẹo tránh khóa? Tôi đo: fast-path đọc atomic không khóa nhanh 314 lần always-lock — nhưng DCL đúng bắt buộc có rào bộ nhớ (acquire/release), thiếu nó luồng khác thấy con trỏ đã publish mà object chưa khởi tạo xong. Một bug ẩn kỹ tới mức Java mất nhiều năm mới thừa nhận.
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.
Cùng một bản ghi, protobuf nhỏ hơn JSON ~2 lần và mã hóa nhanh hơn 7 lần — không phải 'chục lần' như đồn, và gzip còn làm phình một payload nhỏ. Cái lợi thật của gRPC hóa ra không phải vài byte, mà là CPU ở quy mô lớn, hợp đồng lược đồ, và bốn kiểu gọi streaming. Đo thật.
HTTP/2 ghép 20 request thành 20 luồng song song trên MỘT kết nối, xong trong 249ms; HTTP/1.1 sáu kết nối mất 823ms, một kết nối nối đuôi tận 3396ms. Tôi tự tin phô điểm yếu chặn-đầu-hàng-TCP của HTTP/2 dưới mất gói — nhưng phép đo của tôi sai hình dạng nên nó không hiện. Đo thật.
Chạm bộ nhớ RAM thì luôn tốn cả trăm nanô giây? Đo trên host ARM: duyệt một mảng 256 MB theo thứ tự tuần tự chỉ tốn 0,24 ns mỗi phần tử — kể cả duyệt lùi cũng vậy — vì bộ nạp trước đoán và kéo dòng cache về trước. Cùng mảng ấy, truy cập ngẫu nhiên tốn 101 ns, chênh 420 lần. Bộ nạp trước theo kịp cả bước đều rất lớn, chỉ chịu thua kiểu ngẫu nhiên.