记twemproxy的一次性能测试

原创内容,转载请注明出处

Posted by Weakyon Blog on November 21, 2014

twemproxy的性能应该很好,毕竟是twitter在使用的,稳定性应该很高。

然而测试组的同学对其二倍扩容以后,基本没提升QPS,甚至QPS还降低了

我和我的小伙伴们一直以为是客户端或者服务端代码的问题,各种抓包,LOG分析,查不出原因。写了C,JAVA等多个客户端版本。

后面发现原来是测试组的布线坑爹了。

关于之前测试环境redis集群极限qps提升不上去的问题,认定是由于之前4台测试环境部署的宿主机,走的交换机,交换机网络达到瓶颈导致的。

之前性能无法提升的集群架构如下所示:

4台proxy4台redis8台jetty都是独立的虚拟机

之前的测试集群情况

一共4台宿主机,每个宿主机都走一个交换机和其他的机器相连接。看似每台proxy-redis之间互不影响,其实不然,在4台中2台的proxy上取某个key,居然要11秒,另外两台只需要0秒,通过iperf对这两台proxy和该key所在redis之间的网络分别做测试,发现TCP只能跑到20多MB(关闭了所有客户端以后能跑到110MB),导致了测试数据严重失真。C和JAVA客户端扩容后均不能提高QPS。

经过思考以后,决定如下部署:

同样是4proxy4redis8jetty

修改的测试集群情况

Proxy和redis之间走内环,相互都能到理论的128M/S,8台jetty能提供4128M+2128M数据流的压力,足够测试使用

这样的测试环境摆脱了网络的影响,纯粹考虑proxy的计算量如何

使用java线上的版本进行测试3K大小的key,2proxy2redis的情况下进行3分钟的数据采集,平均结果是30536.473 QPS,4proxy4redis后达到61343.87323的QPS,提升了100%

初步认定,达到了扩容后二倍提升性能的需求

另外,4proxy4redis无法提升时网络未跑满,而proxy的CPU跑满了,使用4proxy2redis进行测试,平均53814.31的QPS,提升了76%,观察网络,发现proxy的网络达到瓶颈,而CPU只有80%左右

通过确认线上环境的网络拓扑结构,初步结论是线上环境进行二倍扩容,QPS提升和节点数增加成线性关系。

DBA可以放心扩容


另外附上2redis-2proxy的不同大小KEY下的极限QPS情况:

2redis-2proxy不同KEY下QPS散点图

横轴是KB,纵轴是QPS值。

因此很容易就可以算出来多redis-proxy时QPS上限值:

如4redis4proxy的值,3K时是6W左右,15K时是3W2左右

而4redis8proxy的值,3K时是6W1.76 = 10.56W,15K时是3W21.76 = 5.632W

4redis6proxy的值,3K时就应该是8.28W,15K时是4.416W

最后附上C的redis集群极限测试代码

21 Nov 2014