Performance
测试环境
| 类型 | 配置 |
|---|---|
| MySQL A | Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz (24core 96G) |
| MySQL B | Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz (24core 96G) 日常业务库 |
| Canal Server | Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz (24core 96G) |
| Canal Client | Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz (24core 96G) |
测试方式
为了更加精准的描述canal的性能，会从整个流程上进行优化和分析.
- 整个canal流程处理binlog，分为这么5步操作(4+1)，整个优化和评测对这5步分别进行.
- 构造了两个测试场景，批量Insert/Update/Delete 和 普通业务DB(单条操作为主)
优化内容
- 网络读取优化
- socket receiveBuffer/sendBuffer调优
- readBytes减少数据拷贝
- 引入BufferedInputStream提升读取能力
- binlog parser优化
- 时间毫秒精度解析优化
- 并发解析模型 (引入ringbuffer，拆分了几个阶段：网络接收、Event基本解析、DML解析和protobuf构造、加入memory store，针对瓶颈点protobuf构造采用了多线程的模式提升吞吐)
- 序列化和传输优化
- 提前序列化，避免在SessionHandler里主线程里串行序列化
- 嵌套protobuf对象序列化会产生多次byte[]数据拷贝，硬编码拉平到一个byte[]里处理，避免拷贝
- 客户端接收数据时，做lazy解析，避免在主线程串行处理
- 客户端ack做异步处理，避免在主线程串行处理
优化过程
可参考 github issue详细提交记录： https://github.com/alibaba/canal/issues/726
测试数据
| 序号 | 阶段 | 批量操作Insert/Update/Delete (导入业务) | 单条操作 (普通业务) |
| 1 | Binlog接收 | 200w TPS (网络 117MB/s) | 71w TPS (网络 112MB/s) |
| 2 | Binlog Event解析 | 200w TPS (网络 117MB/s) | 70w TPS (网络 110MB/s) |
| 3 | Insert/Update/Delete深度解析 | 200w TPS (网络 117MB/s) | 65w TPS (网络 105MB/s) |
| 4 | 生成CanalEntry (存储到memory store) | 130w TPS (网络 75MB/s) | 50w TPS (网络 90MB/s) |
| 5 | client接收 | 20w TPS 1.canal server机器网络 11MB/s 2.canal client机器网络 75MB/s binlog膨胀率为 1:6.8 | 10w TPS 1.canal server网络 22MB/s 2.canal client网络 42MB/s binlog膨胀率为 1:1.9 |
各个阶段测试代码：
- FetcherPerformanceTest.java
- MysqlBinlogEventPerformanceTest.java
- MysqlBinlogParsePerformanceTest.java
- MysqlBinlogDumpPerformanceTest.java
- SimpleCanalClientPermanceTest.java
小结
从最开始接收(跑满网络带宽)到最后client机器收到格式化的binlog数据，binlog解析的5个阶段是一个漏斗形的性能。目前整个阶段4->阶段5，性能下降比较明显主要是因为网络传输、序列化的代价影响，binlog接收为了保序采用了串行方式，所以串行里的每个代码逻辑处理都会影响最后吞吐。
如果基于canal做额外的数据扩展，比如对接到MQ系统，可以在步骤3、4阶段介入，最大化的吞吐.
结论数据
- 1.0.26经过优化之后的性能，从业务binlog入库到canal client拿到数据，基本可以达到10~20w的TPS. 相比于canal 1.0.24的4w tps，提升了150%的吞吐性能.
- 单纯的binlog解析能力可以跑到60w ~ 200w的TPS，相当于100MB/s的解析速度