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.
Chi phí của giao dịch Kafka phụ thuộc hoàn toàn vào một con số bạn tự chọn: cỡ giao dịch. Một tin một giao dịch cho 96 tin/giây, cỡ 10.000 cho 639.285 — nhanh hơn cả không giao dịch. Đó là một chi phí cố định 10,4 mili giây được khấu hao trên số tin; nhưng gói càng lớn thì tin đầu tiên chờ càng lâu, vì read_committed không thấy gì tới khi cả lô cam kết.
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.
'Kafka giữ thứ tự tin nhắn' đúng một nửa, và nửa sai là nửa gây sự cố. Tôi đo: thứ tự chỉ được bảo đảm trong một partition, không phải trong một topic. Và vì khoá định tuyến bằng băm chia lấy dư cho số partition, tăng partition làm gần một nửa khoá chuyển chỗ — tin cũ và tin mới của cùng một khoá rơi vào hai partition khác nhau, thứ tự vỡ vĩnh viễn.
Kafka nhanh vì gần như không làm gì phức tạp trên đĩa. Tôi mở tệp .index ra đọc từng dòng: một segment 4.992 tin chỉ có 63 mục — một dòng cho ~79 tin. Đủ để nhảy gần đúng rồi quét nốt, nên tìm một offset bất kỳ gần như miễn phí. Đây là đánh đổi chỉ mục thưa, và vì sao đọc lại từ giữa log không tốn gì.
Lag là chỉ số quan trọng nhất của một hệ thống Kafka, và cũng là chỉ số bị đặt cảnh báo sai nhiều nhất. Tôi đo cùng một trạng thái theo hai cách: hai triệu tin không hành động được, còn 102,6 giây thì trả lời ngay mọi câu hỏi. Cùng 100.000 tin lag có thể là 5 giây hoặc 2,8 giờ — chênh hai nghìn lần, tuỳ tốc độ.