坚信科学,分享技术

>>>尝试更加利于阅读的2014版科学院,以后都在新版上写。

resin+thrift压力测试报告

thrift resin
基础条件

位置 参数
server resin 4
1 rose+1 thrift
java version "1.6.0_29"
Ubuntu 10.04 LTS
双核cpu
8G mem
client macbook pro
ab

server代码
1.用thrift创建了一个方法,内部只有几行代码:

logger.info("in call");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
logger.info("sleep error");
}

2.使用的paoding-rose调用这个thrift方法。

第一波,thrift 10 thread/sleep 1s/rose timeout 3s,ab 100并发发1000次请求
ab -n 1000 -c 100 http://10.235.7.249/test

Complete requests: 1000
Failed requests: 980

试了多次,一定在20次请求时开始超时,服务器端大量timeout。

第二波,thrift 10 thread/sleep 300ms/rose timeout 3s,ab 100并发发1000次请求

Complete requests: 1000
Failed requests: 386

一二波结论
同第一波,还远未触及resin的thread上限(free版本有thread限制)。
这个值大概可以计算出来:
thrift: (1s/300 ms)×10 thread = 33req/s ,
resin: 3s timeout,大概能够处理进入不超时的连接为 33req/s × 3s = 99 req,100个并发进来,大概会随机timeout掉1个甚至更多。
第二波花了30s左右,所以会有两三百的timeout引发的500失败出现。

逆向思考:
如果需要resin的qps达到1000qps,client 1s timeout,而thrift保持300ms话,需要thrift thread: 300-400

于是得出一表格:

resin qps thrift client timeout thrift return time thrift server thread
小于1000 1s 300ms 300-400
小于1000 1s 10ms 10-20
小于100 100ms 10ms 10-20
小于2000 300ms 10ms 100-200
小于330 100ms 30ms 100
小于100 60s 3s 100

第三波,thrift 100 thread/sleep 30ms/rose timeout 100ms,ab 100并发发1000次请求
这次在日志中出现了非thrift timeout的异常了,而是thrift client在未关闭已经完成的处理时,新请求进来了,将会得到获取sokect失败的异常。(这种异常算是池化连接对其性能损耗,在产品工作状态下,应该优于未池化的情况。)

Complete requests: 1000
Failed requests: 681

第四波,thrift 100 thread/sleep 3s/rose timeout 60s,ab 100并发发1000次请求

Complete requests: 1000
Failed requests: 0

因为rose timeout为60s,所以所有的等待都基本上会得到返回,当把并发加大到200也没有处理失败的情况,原因是http的默认超时应该是120s。通过netstat看server的80连接已经到了1002个。

第五波,thrift 1000 thread/sleep 3s/rose timeout 120s,ab 4000并发发50000次请求
这都快成了long polling server了。。。
这个状态下,load到了6,内存吃满。

# netstat -anop|grep :80|grep EST|wc -l
4229
# jstack 26485 | grep -c http
8001
# jstack 26485 | grep -c resin-
93
Complete requests: 50000
Failed requests: 45656

大把大把的超时。

综述
1.提升thrift中逻辑处理速度,减少单个处理时间,是最有效提升thrift qps的办法。
2.thrift thread数量增加一个数量级,前端QPS提升略小于一个数量级。thrift节点数量加1,QPS提升略小于一倍,但不如加thread。
3.resin节点数量×resin qps = thrift节点数量×thrift qps×网络系数,要提高resin qps,可以:提高thrift qps、增加thrift节点数量。此处网络系数肯定小于1。
4.减少不必要的网络系数影响,app+midtier的架构变为service架构,按业务内聚后再SOA化是云后台非常关键的一个原则。
5.resin4的rose框架代码表现在最多4020左右的并发,多于的将会拒绝,类似apache的max-keepalive-connections。
6.tomcat7的同一份代码表现最多在300(未经任何优化)。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]
本文链接: http://www.54chen.com/life/resin-thrift-benchmark.html

This entry was posted in 未分类. Bookmark the permalink.

3 Responses to “resin+thrift压力测试报告”

  1. zhaown 说:

    请教下:

    “thrift 10 thread/sleep 1s/rose timeout 3s“,是说resin中的thrift client的timeout是3s对吧,有时对resin中的逻辑也想限时怎么做呢?比如Controller中的逻辑希望在500ms内完成,否则走backup逻辑。

    “app+midtier的架构变为service架构”请问怎么理解呢,是说分层的rpc变成网状的rpc,调用栈的深度变浅吗?app+midtier有哪些经典例子呢?

    • 54chen 说:

      你可以考虑在resin前面加一层nginx,使用nginx的upstream来调节返回时间和backup。

      理解正确。经典例子可以看resin官方的文档就是给出的app+midtier。

      • zhaown 说:

        哦,多谢了,但是我们的resin的backup逻辑也比较复杂,如果nginx转到另一个backup resin,有些计算要重做...看来resin还是只做接入层算了,不要做太多逻辑

        resin官网的文档太多了,木有app+midtier例子,不过意会一下算了

        ps.这个reply不会发邮件的啊,我还刷邮箱等回复呢:)

Leave a Reply