对于XL改进方案的初步分析

根据前一篇博客中统计的单个事务耗时分布，我们发现每个请求在datanode执行的时间与PG执行时间几乎一样。

之前测试的是短事务，一个事务一个insert语句写入一条数据，这种场景对于xl来说没有什么优势，除了执行写入还要增加网络交互的耗时，且insert操作本身很快完成，相比执行网络交互耗时占的比重就大了很多。

而后我们测试了一下长事务，也就是一条sql执行本身就比较耗时，且能够调动xl多个datanode共同处理的情况。每个事务一条sql，写入10万行数据，这次的执行结果大不一样。

PG在8并发时tps到达上限(25)，XL在32并发时到达tps上限(52)，2并发及一下PG的性能略优于XL，2并发以上XL的性能明显优于PG。

 

由此我们总结出，XL能体现优势的场景，是网络开销在整个事务中所占的比重小，且能充分调动datanode的处理能力的场景。

 

结合之前画的XL事务处理时序图和XL进程架构图，对于XL的性能问题，有以下改进方案(有待补充)：

1. 减少网络交互次数

• 合并请求，比如合并获取GTXID和snapshot的请求(对短事务提升相对明显)  ***
• 使用其他方案实现事务可见性判断(替代现有的集群快照) *****'

 减少网络交互次数的改进方案对OLTP性能的提升空间：

   最好：去除全局事务ID性能可提升15% ； 去除集群快照性能可提升 16%；

   最差：无提升 ( 当sql执行时间远大于获取全局事务ID和集群快照的时间 )

   常见：去除全局事务ID性能可提升9% ； 去除集群快照性能可提升 12%；

    

2. 提高网络传输效率

• 更换传输协议 ****

    【Quic】: 相比TCP减少了建立连接时三次握手的时间, 在弱网环境下比较有优势。（没有找到TCP和QUIC的性能详细对比，以下Quic和HTTP的性能对比作为参考）

       最好：比HTTP快30-50%；带宽很低 (2-10M左右)、RTT很高(200ms以上)的场景 

       最差：比HTTP更慢；

       常见：无提升。

   【RDMA】: 相比TCP减少了传输时 数据在内存、处理器Cache、网卡buffer之间的拷贝，降低网络延时和CPU消耗。

        最好：比TCP提升一个数量级；机器非常繁忙的场景? (待确认)

        最差：无提升；

        常见：比TCP快45%左右；

3. 减少coordinator与datanode的重复步骤

• 执行计划只在coordinator生成，再下发到各个datanode执行。 ****

减少coordinator与datanode重复解析sql和生成执行计划的重复步骤，对OLTP性能的提升空间：

      最好：5%

      最差：无提升

      常见：3%

 

 

【事务处理流程时序图】

 

 

【进程架构图】