项目背景:
想针对某系统的首页进行性能优化,经埋点在ES里面分析,未处理订单通知模块是导致应用服务器CPU高的主因。
分析:
了解到这个模块是采用的技术是主动轮询的机制,每小时有500w的请求量,我们分析了主动轮询的请求里面,默认设置的30s的轮询间隔时间,大概会有1500的QPS,这个请求量对服务器的性能是有一定的影响,且分析到这里面其实有90%的无效请求。
那么该怎么样减少服务端的压力?
方案1: 继续使用轮询的方式,增加资源(服务器,redis,数据库),继续保持30s的轮询间隔时间或者更长的时间。
但方案1有个问题是, 当系统用户增多以及对消息及时性要求增加时,这种轮询接口就会给系统造成很大的压力。且随着系统使用率的提高,该接口的QPS还会继续提升。
如果能够做到后端服务主动将消息推送给客户端浏览器,这样能够减少无效请求,且消息能够及时。这样会带来特别大的改善?
有了上面的讨论,于是方案2的落地: 采用websocket的方式,实现服务端推送消息。
but,问题又来了,我们的客户使用的IE版本各不相同,少部分的使用的还是IE低版本浏览器,但只有IE10及以上版本才支持websocket。
继续讨论。。我们需要一个屏蔽浏览器的且还支持websocket的框架。
于是我们的开发小哥哥们开发了一个将websocket和polling机制以及其它的实时通信方式封装在一起,做了一个浏览器消息实时推送的平台。且称为C平台吧。 (这个平台也就是我们的测试范围啦~~)
待测系统的框架了解:
在前面的项目介绍里面,其实已经聊到了很多。再理下:
1、浏览器调用C平台建立连接,带上userid,sid(sid为业务id)。
2、C平台告知业务系统用户连接已经建立推送hermes消息的uid。
3、业务系统通过提供的Client直接调用推送接口,完成推送。
4、C平台server通过userid的关系将消息推送给浏览器端。
下面画了几张图:
浏览器端发起连接并注册消息。
客户端注册的示意图1
订单写入hermes队列
hermes消费端job
了解项目的测试范围后,怎么来分析测试需求;
本次的调优出发点原本是通过减少首页未处理订单的qps,以达到减少服务器的压力,从而提高服务器的性能。那针对本次的调优思路后,测试重点转化为C平台的性能如何。
再拆分需求:
1.因为是websocket的连接实现的技术,那么C平台到底能支撑多少的连接呢?是否能满足系统用户的需求呢?
2.在已经建立连接后,推送接口的性能如何?占用系统资源多少?
hermes是不是能够及时处理这些数据呢?
再转换为:
看C平台单台服务器的能支撑客户端最大是多少?此时C平台服务器的性能消耗。
2.获取推送接口的性能表现
在建立websocket连接的基础上,获取查询uid接口性能表现。
4.在2的情况下,hermes是否存在数据积压。
测试指标分析:
需求清楚之后,测试转换为的场景其实就是一个长连接的测试,2个接口的容量测试。
引导开发小哥哥们,我要获取以下几个指标:
1.单台服务器需要满足峰值的长连接数是多少? 服务器资源分别不能超过多少?
2.推送接口的数据量是多少? 会推送几种不同的消息体大小 ?
3.查询uid的接口,按最大uid多少进行?
4.job支持最大的并行处理能力是多少?
测试场景:
指标获取后,就是测试场景, 三个负载及两个容量测试:一个长连接的测试,后面2个接口的容量,都是基于建立好长连接后才能开始。
混合场景: 在已经建立好websocket长连接情况下,针对2个接口做混合测试,查看单台服务器的整体性能表现。
测试脚本:
2个post接口的脚本没有啥好聊的,在建立好连接的前提下,设置好固定的TPS跑就可以了。
说说第一个建立websocket的,挺有意思的~~
我们要模拟A系统前端和C平台建立连接, 没有办法直接录制请求,从前面了解到是用websocket,只能手写请求,(当时还没有jmeter3.2的版本,界面不支持websocket,当时用jmeter3.0,下了一系列的jar放进去。。 )
开始直接打开jmeter加了个websocket的sampler,手写请求,发送,然后请求一直一直是失败的。NO.NO.NO!
why?why?why?
于是打开了抓包工具fiddler看前端系统的未处理订单的请求,看到前面其实还有两次http的请求。
前面2次的http的get操作,第一次要获取一个id,第二次把第一次获取的id再http发出去。
然后才是websocket,才开始初始化,建立命名空间,建立连接,获取推送等一系列的操作。
脚本
相关的websocket的jar包
测试执行:
因为要求的目标连接数比较大,在建立websocket连接的时候,我这里用了20台高配的执行机~~~~ (有点想吐槽jmeter本身的性能,捂脸~ )
其他的此处省略一万字的循环,有问题的可以私我~
测试结果:
具体的结果就不贴出来了,此处也省略一万字的循环。有问题的可以私我~
整体的优化效果:
具体的监控对比图就不上了。看看几个数据:
平台上线后,QPS从1500 降到了 200.
应用服务器的CPU得到明显的改善,总体的指标下降50%
对redis服务器的请求,QPS从2500降到了600
总结:
从这次测试来看,很早的参与进来,换个角度站着看性能优化。还是挺有意思的~
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。