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ỗi cookie bạn đặt được đính vào MỌI request tới miền — kể cả ảnh và CSS không dùng nó. Một kho cookie 147 byte khiêm tốn nhân với 30 request thành ~4,4 KB tải lên mỗi lần xem trang, và một ngày đẹp trời cookie phình quá trần header có thể làm chết cả trang với đúng một người dùng. Đ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.
Kích thước bể kết nối chính là mức song song của client: pool 1 buộc 30 request nối đuôi (2581ms), pool 30 cho chạy song song (146ms) — nhanh gấp 18 lần. Nhưng lợi ích chững hẳn ngay khi đụng sức của backend, và một bể quá cỡ chỉ tốn tài nguyên. Đo thật.
Mất gói không kéo cái trung bình — nó dựng một vách đứng ~200ms ở cái đuôi p99, nơi 1% người dùng xui nhất đang chịu trận mà bảng theo dõi trung bình không hề thấy. Và tôi vào bài chắc mẩm jitter là thủ phạm chính, hóa ra sai. Đo thật bằng netem.
Trang 40 tài nguyên nhỏ: qua 10 mbit là thời gian chững ~520ms, nhưng RTT kéo nó tăng tuyến tính. Một file 5MB thì ngược hẳn — gấp đôi băng thông là gần nửa thời gian. Cái nào là nút thắt hoàn toàn tùy hình dạng tải, và một câu châm ngôn nghe rất kêu chỉ đúng một nửa. Đo thật bằng netem.
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.