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.
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.
Container thấy 10 lõi nhưng cgroup chỉ cho dùng 2: 8 luồng bận chỉ đạt 4 giây-lõi thay vì 16, bị đóng băng 20/21 chu kỳ. nproc vẫn nói dối là 10. App 'chậm' dù host rảnh là bị throttle — chẩn đoán bằng cpu.stat chứ không bằng nproc/top, và đặt thread pool theo quota cgroup.
Sách bảo naive O(n·m) chậm, phải dùng KMP. Nhưng trên văn bản ngẫu nhiên naive chỉ 1,04 so sánh mỗi ký tự — gần O(n), còn nhỉnh hơn KMP. O(n·m) là trường hợp xấu nhất, chỉ bật ra trên văn bản lặp (T='aaaa', P='aa..b') nơi KMP nhanh 194 lần. Nhãn xấu nhất không phải bản án cho mọi đầu vào. Tôi đo.
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.