初版发布日期为2018年10月26日，作者为伊藤雅博，所属公司为株式会社日立制作所。

首先

本帖介绍了在2017年Enterprise开源会议上演讲的“目标！成为Kafka大师~如何在Apache Kafka中实现最佳性能”的验证内容（共8次计划）。本帖内容基于2017年6月发布的Kafka 0.11.0版本。

本次活动是第五次，我们将介绍在调整生产者和经纪商之间的传输吞吐量时的性能测量结果。

投稿一覧：
1. Apache Kafka的概述和架构
2. Apache Kafka的生产者/代理/消费者工作原理和设置列表
3. Apache Kafka的推荐配置和性能估算方法
4. Apache Kafka的性能验证(1): 验证环境和参数调优的内容
5. Apache Kafka的性能验证(2): 生产者调优结果 (本投稿)
6. Apache Kafka的性能验证(3): 代理调优结果
7. Apache Kafka的性能验证(4): 生产者再调优和消费者调优结果
8. Apache Kafka的性能验证(5): 系统整体延迟问题

制作人-经纪人之间的性能调优

调音范围

根据上一次的帖子所述，首先要对Producer的发送性能进行调优，以优化Producer-Broker之间的通信吞吐量。在这里，我们的目标是理论上的最大吞吐量1170MB/s。为了排除Broker端的日志刷新和复制的影响，在这个验证中，我们使用acks=0来进行调优和测量。我们在下图中用红色标示了这个验证中的调优范围。

批处理大小和发送延迟时间的调优。

生产者传输的批处理大小由批处理的最大大小（batch.size）和等待批处理积累的时间（linger.ms）决定，所以我们同时调整了这两个参数。下面是在只使用一个生产者节点和一个生产者进行测量时的生产吞吐量。

从上述结果可以得出结论，批处理大小的调整对效果有很大影响，而延迟时间的影响很小。在这个测试中，当批处理大小为128KB，延迟时间为1ms时，生产吞吐量从300MB/s提升到了371MB/s。

制片人对音调进行了调整。

接下来，我们增加了2台Producer节点，并以2的倍数增加Producer数量进行了测量。以下展示了在增加Producer数量时Produce、Replicate和Consume吞吐量的变化。由于本次验证使用了Replication factor为3，所以会在Broker之间复制Produce数据的两倍量。因此，Replicate吞吐量最多达到Produce吞吐量的两倍。因此，在图表中我们会显示Replicate吞吐量的一半值（Replicate/2），以便于与Produce/Consume吞吐量进行比较。

将Producer节点数量增加到6个（每个Producer节点有3个），Produce的吞吐量超过了理论值1,170MB/s。这是因为Broker端的Replicate吞吐量有延迟，可以利用剩余的网络带宽。当Producer数量为1时，Produce、Replicate和Consume的吞吐量是相等的，但随着Producer数量的增加，Produce、Replicate和Consume的吞吐量开始有所差异。

通过这个测量，生产者发现只需要6台设备就能实现超过1,170MB/s的生产吞吐量。

压缩类型的调优

接下来，我们将展示将批量记录压缩的生产者的生产吞吐量。由于吞吐量是以压缩后的字节速率计算的，所以发送的记录数量将根据压缩比例而变化。

我们实际想要最大化的不是压缩后的字节速率，而是发送记录数的速率。以下是示例。

根据上述结果，可以确认gzip的压缩比较高但字节速率较低，而snappy和lz4的压缩比较低但字节速率较高。然而，当比较记录数时，没有压缩（none）的情况下具有最高的吞吐量。

经纪人的 num.network.threads 的调优

最后，我们对接收记录的Broker端的Socket服务器的网络线程数（num.network.threads）进行了调整。以下是我们的测量结果。

尽管增加了网络线程数，但生产吞吐量几乎没有改变。以下是每个网络线程的CPU使用率（每个经纪人有3个线程，总共9个线程）。此时，CPU使用率约为40％，并没有成为瓶颈。通过这次测量，我们确认了网络线程数为3个是没有问题的。

调整结果总结

我已整理以下是此次调整的结果。通过这些调整，生产者的传输吞吐量从300 MB/s提高到1,237 MB/s。然而，由于复制和消费吞吐量尚未达到目标性能，因此中介服务器和消费者也需要进行调整。

最后。

这次我们介绍了对 Producer-Broker 之间的通信吞吐量进行调优的结果。下次我们将会介绍 Broker 的调优结果。

第6回：Apache Kafka性能测试（3）：经纪人调优结果