通过使用shennong的kafka测试程序，得到的单topic单客户端结果较kafka自带的bench结果落后几倍的性能，于是进行了艰苦卓绝的寻找过程，发现最主要的原因是生成每个消息时调用的string format开销，此外avro的序列化和key的序列化也带来一些性能开销。
1. String.format开销较大
重复调用时，考虑使用预计算
2.随手纠正可能存在的性能瓶颈
重复调用无用的String.format在第一次写代码时，已经注意到，但是没有仔细思考，评估其可能的影响。
遇到可以优化的代码，能够及时优化的，最好及时优化，如果方便改动的话。
3.寻找“bug”过程中确认的几件事情
执行代码位于主线程，还是线程池中，不影响结果 --》线程几乎是等价的；类库提供的接口基本无错误
排查多个阶段的影响时，按优先级进行排查有助于事半功倍；
draft process：
#### throughput can't increase
the value serialize method is consistent, what other reason?
thread model related? NO!
string.format for every msg? root cause, as this operation is time cost, the producing pressure can't pass to kafka lib's thread, so the cpu usage is always low, < 200, after move this, cpu usage up to 300, as benchamark's show.
for loop?
网友评论