OneProxy :: 如何做到单实例50万QPS转发性能?需要机器各部件的配合才行。

针对读写分离方案水平分库分表方案架构,最好是有一款极高性能的基于协议的SQL中间件来智能地转发应用程序的请求到后端的MySQL / PostgreSQL集群,应用端的解决方案会增加应用研发的成本以及系统的运行成本,随着应用虚拟化、Docker化后,数据库的连接也会水涨船高。可以看到基于协议的中间件的优势,唯一担心的是多一层转发后的性能问题。从中间件本身的运行维护来讲,太多的中间件实例也会增加管理成本,还好单机上的单个OneProxy实例可以压测到50万的QPS,下面是是压测后的几点经验分享。

    • 尽量选择高主频并且多核的CPU,如果单颗CPU能超过10个核,并有较大的L3缓存,那是再理想不过了。平民软件推荐使用单颗多核的Intel® Xeon® Processor E5-2697 v3 (35M Cache, 2.60 GHz)E7-8867 v3 (45M Cache, 2.50 GHz) 这两款CPU,以确保硬件性能。
    • 最好使用几块千兆网卡,或者两块万兆网卡进行多活绑定,以防止网络成为关键制约。在50万QPS的压力下,即使每次交互只有1000字节(包含TCP的控制信息,实际上只能传递300字节的用户数据),最后的网络流量会达到500MB, 至少需要4Gb的网络带宽,并且最好是使用全双工多队列的网卡。
    • 需要选择较新的内核版本,以避免撞上闻名的Big Kernel Lock 性能问题。我们推荐升级到Kernel 2.6.32-573.7.1.el6.x86_64或3.10.0-229.el7.x86_64版本;并且优化一下网卡中断多核平衡,以防止所有的中断都由一个CPU核心来处理。
    • 设置OneProxy中间件的“event-threads”参数为操作系统中看到的CPU核心的个数,太少的并发线程不能充分利用硬件资源,太高的并发设置又会引起过多的上下文切换而降低性能。
    • 使用最简单的SQL来测试OneProxy的性能,比如”select 1″,以防止后端的数据库成为制约性能的关键。当使用平民软件的mydbtest测试工具来压测“select 1”时,不会真的和后端的数据库有交互,先确保这种场景下的高性能,然后再去压测需要后端数据库配合的SQL语句。
[root@localhost]# ./mydbtest_linux64.bin query=test1.sql degree=240
Summary: SQL01 exec=108589776, rows=108589776=100/e, avg=398 us
Summary: exec=593386/s, qtps=593386/s
    • 最后一步是使用最简单的需要和后端MySQL节交互的SQL语句来压测,请使用“select /* fromdb*/ 1”来进行测试,MySQL可以在Server层完成这条命令,不会让MySQL成为问题的关键,应当会得到一个非常高的QPS值。但仍有可能压到单个MySQL节点的上限,这时你可以配置一个一主多备的读写分离环境来解决MySQL端的问题。
[root@localhost]# ./mydbtest_linux64.bin query=test1.sql degree=260
Summary: SQL01 exec=78136891, rows=78136891=100/e, avg=598 us
Summary: exec=429323/s, qtps=429323/s

如果在你的环境上,用最简单的SQL能压出比上面更高的值后,再开始做真实SQL的50万QPS压测。这是一件非常不容易的事情,需要操作系统/网络/内核/数据库等多方的配合,也会挑战你的知识面是否足够广宽。