Tôi dựng một broker Kafka hai cổng — PLAINTEXT và SSL — rồi đo cùng phần cứng, cùng dữ liệu: ghi với TLS chậm 20%, nhưng đọc chậm 2,2 lần, và cột SSL gần như phẳng trong khi PLAINTEXT tăng dần. Khác biệt không phải ngẫu nhiên — mã hoá giết chết sendfile, cái đường tắt zero-copy mà chỉ phía đọc mới được hưởng.
retention.ms là mức *sàn*, không phải hạn chót: việc dọn chạy theo chu kỳ 5 phút và chỉ xoá nguyên cả segment. retention.bytes tính theo từng partition và làm tròn lên một segment, nên đĩa thật gấp 3,4 lần con số bạn viết. Đây là công thức dự trù đĩa đúng, và vì sao 'xoá sau 30 ngày' không phải một bảo đảm tuân thủ.
'Đặt nhiều partition cho chắc' là lời khuyên phổ biến và tốn kém. Tôi đo cả hai vế: phía ghi một partition đã gần chạm trần, thêm consumer bão hoà ở 1,7 lần chứ không phải 4 lần, còn 2.000 partition rỗng đẩy bộ nhớ broker từ 290 MB lên 973 MB. Partition là đơn vị song song, không phải nút vặn thông lượng — và tăng thì được, giảm thì không.
Xếp một pod lên node chỉ tốn khoảng 50 mili giây. Nhưng bộ lập lịch cộng 'requests' chứ không nhìn CPU dùng thật — nên node có thể 'đầy' trong khi thật ra rỗng, và một pod PriorityClass cao sẽ đuổi pod đang chạy để lấy chỗ. Bài này đo cả ba hành vi đó.
Kafka hay được khen nhanh nhờ 'zero-copy' và 'page cache', hai cụm từ ít khi được đo. Tôi đo cả hai: một broker 1,2 GB phục vụ 1.130 MB/giây, và khi xoá sạch bộ đệm trang, đọc lạnh chỉ chậm 1,6 lần chứ không phải hai bậc độ lớn — vì Kafka đọc tuần tự, và với truy cập tuần tự thì bộ đệm gần như là tuỳ chọn.
kube-apiserver là cửa duy nhất vào cụm, nặng 265 MB — gấp năm lần etcd. Nhưng phần việc thật của nó cho một lệnh kubectl chỉ 4–8 mili giây; 24 mili giây còn lại là binary khởi động. Bài này đo chi phí một lệnh, cơ chế watch thay cho hỏi liên tục, và chỗ nguy hiểm nhất: webhook admission nằm ngay giữa đường ghi.