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.
Mọi hệ lưu trữ phải trả lời: ghi vào bộ đệm hệ điều hành đã coi là an toàn chưa? Kafka trả lời khác PostgreSQL, và tôi đo cái giá: fsync mỗi lô kéo thông lượng từ 540k xuống 170k tin/giây. Kèm một câu chuyện về phép đo hình chữ U mà tôi suýt công bố — hoá ra do một lệnh tạo topic hỏng bị nuốt lỗi.
Suốt mười năm Kafka cần ZooKeeper; từ 4.0 thì không. Tôi dựng cả hai kiểu cạnh nhau: KRaft nhanh gấp chín lần, nhẹ hơn, bớt một tiến trình. Nhưng bài học đáng nhớ hơn là khi ZooKeeper chết, Kafka vẫn ghi đọc bình thường — chỉ mặt phẳng điều khiển dừng — và bỏ ZooKeeper không có nghĩa bỏ được yêu cầu đa số 2f+1.
Kafka coi mọi tin là mảng byte, nên đổi lược đồ là trách nhiệm của bạn. Tôi đo cái giá khi làm sai: một tin sai kiểu khiến consumer quay ở 692 nghìn ngoại lệ mỗi giây, đốt trọn một nhân CPU, và partition đứng vĩnh viễn ở offset đó. Bảy dòng chữa nó — và cái bẫy thật là một vòng bắt-lỗi lặp lại ngay thao tác vừa hỏng.
Lời khuyên phổ biến là 'đừng dùng JSON trên Kafka, dùng Avro'. Tôi đo cả ba định dạng trên cùng dữ liệu: thô thì Avro nhỏ hơn JSON 2,5 lần nhưng mã hoá lại chậm hơn. Rồi bật nén — mà cụm nào cũng bật — và lợi thế co xuống 1,4 lần, vì nén xoá đúng phần dư thừa (tên trường lặp lại) mà Avro xoá bằng tay. Lý do thật để chọn Avro nằm ở chỗ khác.
Khi một tin không xử lý được, phản xạ tự nhiên là thử lại. Tôi đo cái giá đó ở bốn mức tỉ lệ hỏng: ở mức 50%, thử lại tại chỗ cho 30 tin/giây còn đẩy sang DLQ cho 766 — chênh 25,5 lần. Chi phí của một tin hỏng không phải là chờ nó, mà là toàn bộ hàng phía sau cũng phải chờ theo.