mirror of
https://github.com/didi/KnowStreaming.git
synced 2026-01-10 17:12:11 +08:00
53 lines
2.7 KiB
Markdown
53 lines
2.7 KiB
Markdown
**测试环境：**
|
||
|
||
单条消息大小1KB，随机10000条
|
||
|
||
测试环境：CPU: E5-2630 v4 20C40T 内存：128G 磁盘：2T NVME ES3600P 版本：Dkafka2.5.0 JVM：-Xmx8G -Xms8G
|
||
|
||
服务器端参数：num.network.threads=6 num.io.threads=32 num.replica.fetchers=10 didi.mirror.num.fetchers=10
|
||
|
||
客户端参数：batch.size=16384 linger.ms=100
|
||
|
||
主集群：单个Topic 10个分区2个副本，Leader都分布到同一台机器上，副本都分布在同一台机器上
|
||
|
||
备集群：单个Topic 10个分区1个副本，Leader都分布到同一台机器上
|
||
|
||
线程数：副本fetcher线程10、Mirror fetcher线程10、MM tasks数10
|
||
|
||
|
||
|
||
**非压缩场景**
|
||
|
||
| 性能对比 | 主集群写入 | 副本同步 | Mirror同步 | MM2同步 |
|
||
| :-------: | :--------: | :------: | :---------: | :---------: |
|
||
| MessageIn | 626399/s | - | 537576/s | 263450/s |
|
||
| BytesIn | 619MB/s | 540MB/s | **538MB/s** | **259MB/s** |
|
||
| CPU使用率 | 898.3% | - | 284% | 1558% |
|
||
|
||
**LZ4压缩场景**
|
||
|
||
| 性能对比 | 主集群写入 | 副本同步 | Mirror同步 | MM2同步 |
|
||
| :-------: | :--------: | :------: | :-----------: | :---------: |
|
||
| MessageIn | 770503/s | - | 542501/s | 242615/s |
|
||
| BytesIn | 761.5MB/s | 570MB/s | **557.8MB/s** | **245MB/s** |
|
||
| CPU使用率 | 757.7% | - | 352% | 1802% |
|
||
|
||
**结论：** Mirror同步性能和副本同步原理相同性能接近，Mirror同步在不使用额外资源的情况下性能比MM2同步高出2倍+，**MM2同步在需要额外18核心CPU的情况下达到Mirror同步不到一半的性能**。压测场景下属于理想环境，每次发送的Batch都是满载的，性能效果会比较好，实际线上环境会比较复杂，而副本同步和Mirror同步受Batch大小因素基本无影响，一次可以拉取多个batch进行写入，MM2的性能会受Batch大小因素影响会比较大，具体详见以下补充测试。
|
||
|
||
**PS：**
|
||
|
||
1. 由于是随机消息，所以lz4压缩率比较低
|
||
2. 由于缺少系统监控图表，cpu使用率使用瞬时值，上下会有一些偏差
|
||
3. 副本同步缺乏消息数指标，流量以刚刚出现积压时流量为准
|
||
|
||
|
||
|
||
**补充LZ4压缩场景 （batch.size=5120 模拟batch内消息不足）**
|
||
|
||
| 性能对比 | 主集群写入 | 副本同步 | Mirror同步 | MM2同步 |
|
||
| :-------: | :--------: | :------: | :-----------: | :---------: |
|
||
| MessageIn | 570503/s | - | 549520/s | 102615/s |
|
||
| BytesIn | 598.2MB/s | 570MB/s | **549.7MB/s** | **105MB/s** |
|
||
| CPU使用率 | 2010% | - | 328.8% | 1284% |
|
||
|
||
在一个batch包含消息数比较少（请求数多）的情况下，MM2性能明显降低，而Mirror同步基本无影响，性能相差5倍 |