背景：

今天测试了两种不同的场景下kafka producer的tps性能数据，两种场景下都是使用3个线程，每个线程都是对应一个kafka producer，测试发送到kafka集群的消息的量，两个场景的区别是场景A只发送kafka消息，场景B是除了发送kafka消息之外，还使用logback记录日志(异步模式)，但是得到的发送到kafka集群的消息的量相差较大，大概20%，本文就记录下造成kafka消息发送的tps相差较大的原因

追查原因:

一.还原下测试场景

首先说明下场景A和场景B的压测环境，

服务器：两个场景都是使用12核12G的容器进行测试的
消息大小： 两个场景使用的消息大小都是1k，logback记录到日志中的文本大小也是1k
kafka producer 数量： 两者都是3个生产者，分别对应3个发送消息的线程

最终压测的结果：
场景A也就是只有发送消息到kafka的TPS为80000，而场景B也就是既发送消息到kafka，也是用logback日志落盘的场景TPS为58000，两者相差将近1/3的TPS，

二.分析场景

gc影响： 场景A和场景B压测过程中的gc次数都差不多，总的gc停顿时间都差不多，都没有明显的gc停顿

cpu：在整个压测的过程中场景A的CPU使用率是60%，也就是使用到了12核 * 0.6 = 7.2核，场景B的cpu使用率是100%，也就是使用到了12核 * 1.0 = 12核

分析整个过程中的cpu火焰图，发现场景A中发送kafka消息的Run方法占用的cpu为40%，而场景B中发送kafka消息的Run方法占用的cpu为17%，也就是说场景A中总共使用的cpu核心=7.2核 * 0.4=2.9核，而场景B中总共使用的cpu核心=12核 * 0.17=2.1核,

是不是大概看出了问题所在？

场景A中每个核心发送的kafka消息的TPS为：80000/2.9核心 = 26600，而场景B中每核心发送kafka消息的TPS为：58000/2.1核心 = 27600

这两个场景中归结到每个cpu核上的TPS几乎是差不多的，所以问题也就明显了，场景B中cpu资源不足，也就是logback等模块占用了不少的cpu的资源，导致消耗在发送kafka消息上的cpu资源少了

总结：

1.从这个问题的查找可以得出一个结论，当对两个场景进行压测时，最好不要让cpu跑满100%，因为这样会限制对应场景能获得的cpu的资源，压测的结果就明显受限于cpu。

2.当我们进行压测时，压测的场景要尽量符合真实的场景，因为真实场景下有很多“坏邻居”，比如这里的场景B的logback模块，他们有可能对要压测的指标有很负面的影响.