使用JMH和TopologyTestDriver测试Kafka Streams Join时吞吐量骤降

可能的原因 #

• TopologyTestDriver的状态存储未优化
  KTable依赖状态存储，TopologyTestDriver默认的状态存储配置可能没针对测试调优。哪怕指定了Materialized，如果没开启缓存、没禁用测试环境不需要的持久化日志，每次Join都会触发状态全量扫描或频繁flush，开销远高于直接转发。

• 测试中重复初始化状态
  如果你的JMH测试每次迭代都重新创建TopologyTestDriver、重新加载KTable的输入数据，那每次测试都要全量构建KTable的状态，这是极耗时的操作。而直接转发不需要状态存储，自然速度快很多。

• 序列化/反序列化额外开销
  Join过程中，KTable的状态存储可能会对数据做序列化/反序列化操作（哪怕是内存存储），而直接转发可能只是传递数据引用。如果使用了复杂的Serde，这部分开销会被进一步放大。

• JMH预热不足
  Join的代码路径比直接转发复杂得多，需要更多的JIT编译时间。如果JMH的预热迭代次数不够，测得的是未优化的冷启动性能，数值自然偏低。

• Kafka Streams配置不合理
  比如cache.max.bytes.buffering设置太小，会导致KTable频繁flush状态；或者未指定临时state.dir（虽然TopologyTestDriver默认用内存，但部分配置仍会影响状态存储行为）。

排查步骤 #

1. 单独测试KTable性能：写一个只加载KTable数据的基准测试，看吞吐量是否正常，确认是不是KTable初始化拖了后腿。
2. 调优JMH预热参数：增加预热迭代次数，比如@Warmup(iterations = 5)，确保JVM完成Join代码的JIT编译。
3. 优化状态存储配置：显式给Join指定优化后的Materialized参数，示例代码：

Materialized.<KeyType, ValueType, KeyValueStore<Bytes, byte[]>>as("join-cache-store")
    .withCachingEnabled()
    .withLoggingDisabled();

4. 复用TopologyTestDriver实例：将TopologyTestDriver的创建放在@Setup方法中，让所有测试迭代复用同一个实例，避免重复初始化状态的开销。
5. 查看Kafka Streams Metrics：在测试中获取Metrics，重点关注stream-join-rate、state-store-put-rate这类指标，定位具体性能瓶颈。

内容的提问来源于stack exchange，提问作者user1883202