第一版：2018年11月9日
作者：伊藤雅博，日立製作所株式会社

首先

在这篇文章中，我们将介绍在2017年企业级开源大会上发表的《目标！成为Kafka大师 ～如何在Apache Kafka中实现最佳性能～》的验证内容（共计8个部分）。本文的内容基于2017年6月发布的Kafka 0.11.0版本。

在第七次讨论中，我们将介绍Producer重新调整的结果以及Consumer的调整结果。在第六次发布中，我们进行了Broker的调整，但最终吞吐量大幅下降。因此，这次我们将再次进行Broker调整，然后尝试进行Producer的调整。随后，我们将进行Consumer的调整，以优化从Producer发送到Consumer接收的整体吞吐量。

投稿一覧:
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): 系统整体延迟情况

制片人的重新调整

在前一次测试中，我们发现将acks从1更改为all会显著降低吞吐量。这可能是由于acks值为1时和值为all时，Record Batch大小和Producer数量等方面的合适性不同所致。因此，这次我们将在之前参数优化的基础上将acks设为all，并重新进行Producer的调优。

批处理大小的调整

首先，我们在使用两个Producer节点和三个Producer来重新调整batch大小的情况下，将结果如下所示。

通过将该参数从128KB增加到512KB，生产吞吐量从404 MB/s增加到500 MB/s。

制作人的调整手段 de

下面是Producer数量再调优的结果。Producer节点共有2个，总共有80个核心1，每个Producer在用户线程和网络线程上使用2个核心，因此在本次验证中，我们增加了最多40个Producer并进行了测试。

将生产者节点数从6个（每个Producer节点3个）增加到40个（每个Producer节点20个），生产吞吐量从500 MB/s提高到823 MB/s。如果继续增加Producer节点以增加生产者数量，生产吞吐量可能进一步提高。

调整 num.network.threads 的设置

最后，下面展示了经过再调整的Broker端网络线程数（num.network.threads）的结果。

增加网络线程数并没有显著提高生产吞吐量，但是在增加到14个线程后，吞吐量从823 MB/s 提高到 863 MB/s。

制作人的重新调整结果总结

以下是对制作人重新调谐结果的总结。

通过这些调整，Produce 的吞吐量在 acks=all 的状态下从 404 MB/s 提升到了 863 MB/s。由此结果可以确认，在 acks=1 和 all 的情况下，适当的 batch.size 和 Producer 数量是不同的。

消費者的调试

在进行之前的调优状态下，通过最后对Consumer的取得性能进行调优，从Producer的发送到Consumer的接收，优化整个系统的吞吐量。在以下图表中以红色标出了涵盖了Consumer的调优范围。通过对Consumer的调优，实现对Producer、Broker和Consumer这三个组件的全面调优。

调整fetch.max.bytes的设置

首先，我们将展示Consumer在修改fetch.max.bytes参数后的结果。我们将为该参数设置一个较大的值（1,000 MB），然后通过调整以分区为单位的最大获取大小（max.partition.fetch.bytes）来调整每次获取的大小。

这个变动使得Consume的吞吐量从676MB/s提高到688MB/s，稍微有所提升。

最大分区获取字节大小的调整

接下来，将展示调优后的每个Fetch请求的分区最大获取大小（max.partition.fetch.bytes）结果。

通过将该参数从1 MB增加到7 MB，Consume吞吐量从688 MB/s提高到763 MB/s。

顾客数量的调整

最后，我会在下面展示对消费者数量进行的调整结果。

增加消费者数量并没有显著提高消费吞吐量，但将消费者数量从4增加到6时，吞吐量略有提高，从763MB/s增加到803MB/s。由于消费者处理的开销较小，我认为6个消费者已足够。

消费者调查结果摘要

我已经整理了有关提高Consumer的性能调优结果，如下所示。

通过这些调整，消费吞吐量从676 MB/s提升至803 MB/s。同时，产生/复制的吞吐量与消费吞吐量几乎相等，确认整个系统可以达到803 MB/s的吞吐量。

整个系统的吞吐量评估

在本次验证中，我们完成了Producer、Broker和Consumer的调优，并优化了从Producer发送到Consumer接收的整体吞吐量。通过先前的调优，我们成功实现了使用同步复制（acks=all，复制因子=3，最小in-sync副本=2）平均吞吐量为803MB/s。

这个数值约为网络带宽的理论值（1,170 MB/s）的70%。以下是Produce、Replicate和Consume的吞吐量变化情况。吞吐量的平均值为803MB/s，但是吞吐量随时间上下波动，最高可达到1,000 MB/s（约为理论值的85%）的带宽利用率。

调谐的要点 de

以下是在以前的调整中产生显著效果的参数。

Producer の batch.size

KafkaはRecord Batch単位でデータを処理するため、Record Batchサイズを増やすことで、処理のオーバーヘッドが減りスループットが向上します。また、acks=allではackの返信に時間がかかるため、リクエスト頻度を増やすよりRecord Batchサイズを増やして1回のリクエストサイズを大きくした方が良いと考えられます。

Producer の個数

Producer数を増やすことで送信データ量が増えるほか、Brokerとのコネクション数（並列処理数）が増えるため、スループットが向上します。

Broker の num.replica.fetchers

Replica fetcher数を増やすことで、レプリケーションのスループットが大幅に向上しました。ただし、Replica fetcherに対するPartition割り当ての偏りを回避するため、Replica Fetcher 数をBroker数の倍数にしないことを推奨します。

Consumer の replica.fetch.response.max.bytes、max.partition.fetch.bytes、Consumer Group内のConsumer数

ConsumerのFetchサイズとConsumer数を増やすことでスループットが向上しました。Consumerの処理はProducerと比べてオーバーヘッドが少ないため、Producerと比べて少ない個数でも十分なスループットを出すことができます。

结束了

在过去的验证中，我们关注的是数据处理的吞吐量，并进行了调优。一般来说，吞吐量增加时延迟也会增加，但之前的验证中并未考虑延迟。因此下次我们将介绍延迟的测量结果。

第8回：Apache Kafka在性能验证中的表现(5)：关于整个系统的延迟