Performance & Tuning

ไอเดียในหนึ่งประโยค

การจูน Kafka ส่วนใหญ่คือการเลือกว่าคุณจะนั่งตรงไหนบนเส้นโค้ง throughput เทียบกับ latency batch producer ใหญ่ขึ้น, compression, partition มากขึ้น และ acks แรงขึ้น ต่างดันไปทางใดทางหนึ่ง คุณจึงจูนไปตาม workload ของคุณ ไม่ใช่ไล่ล่าค่า “เร็ว” ค่าเดียว

ปุ่มฝั่ง producer: batching, compression, acks

producer คือจุดที่ throughput ได้มาหรือเสียไปมากที่สุด สามค่าครองเกม

Batching linger.ms กับ batch.size ให้ producer รอไม่กี่มิลลิวินาทีแล้วอัดหลาย record ลง request เดียว batch ใหญ่ขึ้นแปลว่า throughput สูงขึ้นมาก แลกกับ latency ต่อ record นิดหน่อย
Compression compression.type (lz4, zstd, snappy, gzip) ย่อ batch แต่ละอันให้เล็กลง ลดการใช้ network และ disk เป็นการแลก CPU กับ throughput และเกือบทุกครั้งคุ้มค่าเมื่อโหลดสูง
acks acks=all รอให้ ISR persist record (durable, latency สูงกว่า) acks=1 รอแค่ leader (เร็วกว่า การันตีอ่อนกว่า) นี่คือปุ่ม durability เทียบกับ latency คลาสสิก

# Throughput-leaning producer: wait a little, batch bigger, compress, stay durable
linger.ms=10
batch.size=65536
compression.type=lz4
acks=all

flowchart LR
  batch["Bigger batches + linger.ms"] --> tp["Higher throughput"]
  comp["Compression (lz4 / zstd)"] --> tp
  acksall["acks=all"] --> dur["Stronger durability"]
  acksall --> lat["Higher latency"]
  small["Small batches + acks=1"] --> low["Lower latency"]

การแลกเปลี่ยนระหว่าง throughput กับ latency

size partition ตาม throughput

partition คือ หน่วย parallelism ของคุณ partition หนึ่งถูก consume โดย consumer ได้มากสุดหนึ่งตัวใน group จำนวน partition จึงเป็นเพดานของ consumer parallelism ให้กำหนดจำนวนจากเป้าหมาย throughput ที่ต้องการ

partition ≈ throughput เป้าหมาย ÷ throughput ต่อ consumer (หรือต่อ partition)

ถ้า consumer หนึ่ง instance รับได้ 10 MB/s และคุณต้องการ 100 MB/s คุณต้องมีอย่างน้อย 10 partition ให้ consumer 10 ตัวรันขนานกัน ปัดขึ้นแล้วเผื่อ headroom ไว้สำหรับการเติบโตและการกระจาย key ที่ไม่สม่ำเสมอ

ฝั่ง broker: page cache, disk, network

broker ถูกออกแบบให้เรียบง่ายโดยตั้งใจ ความเร็วของตัวเองมาจาก operating system

Page cache Kafka ไม่ ทำ cache ใหญ่ใน process ของตัวเอง แต่เขียนลง OS page cache แล้วพึ่ง kernel ให้เสิร์ฟการอ่านล่าสุดจาก memory เหลือ RAM ว่างไว้เยอะ ๆ ให้ page cache อย่าให้ JVM heap ใหญ่จนไปแย่ง RAM ส่วนนั้น
Disk การเขียนแบบ sequential ทำให้ดิสก์จานหมุนและโดยเฉพาะ SSD มีประสิทธิภาพ ใช้ local disk ที่เร็ว และกระจายโหลดด้วยหลาย log directory ถ้าจำเป็น throughput ของ disk และพฤติกรรม fsync เป็นตัวจำกัด durability กับความเร็ว
Network replication และ consumer fan-out ผูกกับ network replication-factor เท่ากับ 3 แปลว่าทุก byte ที่ produce ถูกเขียนราว ๆ สามครั้งข้าม network จัดสรร NIC ให้เหมาะ