OceanBase专用的OBProxy如何提升单机性能？包括这三个方面

OBProxy产品从 2014年开始设计研发，至今已经有近8年的历史，其产品在蚂蚁内部、专有云场景、公有云场景都有广泛的使用，在访问链路上承担了重要的作用。而为了实现OBProxy高性能特性，研发团队做了大量的工作，其中就包括OBproxy 单机性能优化工作。

综合来说，包括在OBProxy的功能设计和编码实现时考虑性能影响，面向高性能编程，降低新功能带来的性能损耗；关注新的硬件、linux内核和编译器技术，使用新技术带来性能优化；以及建立性能回归体系，对每个版本做严格性能回归，保证性能优化的成果。

接下来，我们就来详细展开看看。

OBProxy高性能设计

OBProxy在设计之初就考虑了高性能：

采用C++语言编写，可以充分使用硬件、内核的特性，也减少一些语言的GC等机制对性能影响；

设计优秀的多线程模型，可以充分发挥每一个CPU核心的能力，架构上做到尽量简单；

编码时采用异步调用、内存池、减少Buffer拷贝等手段优化性能。

如果用一句话概括，OBProxy通过多线程和异步框架提供优异的性能。不过为了满足异步接口的使用，产品也做了一些牺牲，将一个完整的流程会被切割成多段代码，对代码可读性有一定影响。

对于OBProxy的线程模型，下图描述了公有云上OBProxy在16c机器上的任务分发模型。线程主要分为两类：accept线程和work线程。accept有两个，work线程有16个（根据CPU核数确定）。work线程完全一样，accept线程完成TCP建连后，会将对应的套接字轮询的发给每个work线程。每个work线程运行epoll机制， 进行套接字的读写、异常等处理工作。

因此OBProxy可以做到CPU核心之间的负载均衡，充分发挥每一个核心的能力，不存在因为阻塞导致CPU利用率上不去的情况。

OBProxy 优化方向

虽然OBProxy有了优秀的线程模型和异步框架，但随着功能的不断丰富，对性能也会产生一定的损耗。此时该如何提升性能？需要从应用、编译器和内核、硬件三层去做性能优化。

对于应用层的优化，常见做法分为四步：

1、确定优化场景：如数据库常选择sysbench中的场景或者TPCC场景；

2、分析性能消耗：通过perf火焰图、打日志等一些手段获取性能消耗分布， 从大到小，模块、函数、代码语句层层拆分下去，明确问题点；

3、提出解决方案：无论是从设计上还是C++一些优化技巧（如减少拷贝、减少锁使用等）提出优化方案；

4、验证优化效果：根据方案进行编码，并重新验证优化效果。

就大部分情况而言，应用层优化效果都很显著。至于编译器和内核新特性使用，内核和编译器技术也在不断发展，在性能方面也会提供越来越多的新特性，而这些技术发展并应用到实践中，都可以提升OBProxy性能。

硬件方面，主要是探索RDMA在 OceanBase 数据库的使用。对于RDMA，除了大家知道的对延迟的影响，另一个重要作用就是Bypass Kernel，节约CPU，优化性能。在分析OBProxy性能时，可以发现内核态进行TCP报文收发就可能占用30% ~ 50% 的CPU资源。使用Bypass Kernel设计（参考下图），可以进一步提升OBProxy性能。

对于OBproxy项目，版本功能迭代是性能的一大杀手。新的功能特性意味着新代码引入，代码规模进一步变大。除了指令数增加，对Cache命中率等硬件特性影响也会导致下降。因此需要平衡好新功能开发对性能影响：1、在性能设计时考虑性能影响，做评估好性能影响；2、建立完善的性能回归体系，发现每一次的性能变化，并做好记录。

而最后根据工程实践，每个迭代性能损耗可以控制很好。