谁是性能杀手？Kafka 多 Topic 下启用 SSL 时延增大问题分析

问题背景

项目中将 Kafka 接口进行 RESTful 封装，在使用 RESTful 接口进行性能测试时，发现 Topic 数增多后，开启 SSL 与非 SSL 进行测试，发现开启 SSL 后性能下降得厉害。例如 600 个 Topic 总数每个 Topic3 分区 3 副本的场景下，使用 1200 个线程只发送 10 个 Topic，开启 SSL 的 TPS 只有 3100，但是不开启 SSL 性能达到 11000。

其中测试客户端会启动多个线程，每个线程采用同步发送的方式调用 RESTful API 发送，即每次发送成功一条后才发送下一条。 客户端会根据发送线程在 Topic 数之间进行均分，例如 1200 个线程发送 10 个 Topic，则每个 Topic 同时有 120 个线程进行发送。

定位与分析过程

1.SSL 性能下降

1.定位分析

开启 SSL 是会导致性能下降的， 主要来自于 CPU 的耗时与 JVM 的具体实现，参见 Kafka 官网的解释：

从我们之前测试的结果来看，高可靠场景 SSL 性能下降并没有太厉害（从 2.3W TPS 下降到 2.1W TPS）。应该是触发了某些其他问题。通过 JStack 查看启动 SSL 下的堆栈，发现存在一些发送线程被 Block 住：

这个堆栈里面做的事情，是来自于 java.security.SecureRandom 要产生随机数，采用”SHA1PRNG”算法。在 sun/oracle 的 jdk 里，这个随机算法的的实现在底层依赖到操作系统提供的随机数据，默认用的是/dev/random，在读取时，/dev/random 设备会返回小于熵池噪声总数的随机字节。/dev/random 可生成高随机性的公钥或一次性密码本。若熵池空了，对/dev/random 的读操作将会被阻塞，直到收集到了足够的环境噪声为止。这个问题在网上也查到，主要是 JDK 提供的 SecureRandom 函数存在 1 个全局的锁，在熵源不足且 SSL 线程多的时候很容易碰到这个问题，具体见：

https://github.com/netty/netty/issues/3639

http://bugs.java.com/view_bug.do?bug_id=6521844

2.解决措施

措施一：更新 JDK

目前这个问题是在 OpenJDK 1.8 中解决了，可以通过升级 JDK 到使用 OpenJDK，但是这个方案不太好替换，并且 OpenJDK 和原来有什么不兼容还不清楚。

措施二：采用非阻塞的熵源: /dev/urandom

通过设置-Djava.security.egd=file:/dev/./urandom 宏，随机数时选择/dev/urandom，它会重复地使用熵池中的数据以产生伪随机数据避免阻塞，不过随机安全性会降低。

2.Topic 多情况下性能下降

1.定位分析

发现在 Topic600 个情况下，非 SSL 与 SSL 的时延其实差距并没有原先发现的问题那么大，以下是我们用 SDK 接口测试的时延数据：

600 个 Topic 总量下，400 个线程同时发送 10 个 Topic，非 SSL 与 SSL 时延对比：

可以看出时延差距在 20%之内，主要的时延增加来自于 Topic 增多导致的。

为什么 Topic 增多会导致时延增多？针对这个问题通过在程序进行打点测试，以下是在不同的 Topic 数量情况下，针对 10 个 Topic，总发送 5000 条消息的场景下，非 SSL 时延对比：

其中总时延 = 消息的待发送队列等待时延 + 服务端处理平均时延 + 网络发送与响应时延。

从上面的表格可以看出基本上每个处理环节上都增加了时延 4~5 倍。为什么会出现这种情况？分析如下可能点：

1 磁盘的写速度变慢

2 Server 由于 Topic 多需要过滤信息变慢

3 复制处理在多 Topic 下变慢。即使无数据，多 Topic 下复制线程也会一直发送空请求

4 Topic 多资源占用大

通过逐一分析、排除与测试，主要原因还是在第三点：服务端在复制处理在 Topic 数量多的情况下变慢导致的。

例如 10 个 Topic 的时候，如果用 10 个复制线程（目前性能测试就是配置 10）用于副本复制，则每个复制线程会分配到 1 个 Topic；而当 Topic 有 600 个的时候，如果还是 10 个复制线程用于副本复制，则每个复制线程会分配到 60 个 Topic。 如果此时只发送前 10 个 Topic 的时候，很有可能只有 1 个复制线程在工作，其他的复制线程由于分配到的 Topic 没有数据，基本处于空闲状态。

2.解决措施

既然复制线程变慢，我们可以通过继续增加复制线程的方式提高性能，在 600 个 Topic 场景只发送 10 个 Topic 场景下，我们把复制线程提升到 60 个，这样 10 个 Topic 能尽可能分配到不同的复制线程中，提高了复制的速度。以下是实际测试结果：

可以看到增加到 60 个 fetch 线程后，时延变为 100ms 左右。同时原来的环境下，通过增加复制线程（修改配置 num.replica.fetchers=60），在原环境下 1200 个发送线程即使启动 SSL，性能也能达到 11000+。

性能提升措施总结

RESTful API 是同步接口，但是内部使用的 SDK 接口是异步发送。根据高可靠场景下异步发送的能力能达到 2W+ TPS 来看，主要还是同步接口的并发压力上不去导致的，可以通过以下措施来改进：

1 增加请求等待时间linger.ms

通过在客户端增加参数linger.ms，使得每个请求回等待指定的时间后再发送，使得每个请求可以发送更多的数据，即增加合包率。

2 增加同步发送对同 1 个 Topic 的并发数量

3 减少 Topic 的分区数

因为目前 RESTful API 并没有用尽服务端的能力（1 个分区的能力瓶颈还没达到），默认的 3 个分区是浪费资源，并且会导致合包率降低，如果采用 1 个分区，则同样的压力下，合包率能提升 3 倍，这样性能也能提升。这个措施还可以支持更多的 Topic 数。

4 增加复制线程

5 考虑提供异步发送 SDK 接口

本文转载自公众号中间件小哥（ID：huawei_kevin）。

原文链接：

https://mp.weixin.qq.com/s/VJMHdEgTYsLK_2TGFrqyKA