1背景介绍
近期在做特效厅需求，所谓特效厅就是每个影厅的一种属性，例如：3d,imax,杜比，4k等等。
2 为什么需要压测
我的理解就是保证系统高可用，通过一些模拟保证线上在大流量的情况下依然可用。
那特效厅这个需求为什么需要压测呢？
c端影院进入就会取特效厅，从历史的数据来看，QPS峰值是7000，目前有20机器，也就是说单机的QPS需要能抗住350。我们给交易提供thrift接口，双方约定，接口请求到返回的时间不能超过300Ms，通过这些数据我们就能知道，我们压测的目标是，单机350QPS，耗时300Ms以内。
2 曲折的压测过程
2.1 压测前期准备
首先，需要给测试同学准备压测的数据（这个数据完全模拟线上），其次，需要给测试同学搭建测试环境，因为这个是用到squirrel作为缓存所有需要搭建ppe的squirrel环境，测试部署到
gh-movie-oa-bd-perf01 （4C8G）gh-movie-maoyan-eye-perf01 （4C8G）两台测试机上。压测接口：
压测接口
image.png
好了到此为止，压测环境准备完成。一下都以querySpecialHallByCinemaIds这个接口为例做分析
2.2 线下压测
2.2.1测试报告
image.png
2.2.2报告分析
在线下对该接口进行压测，平均响应时间一直在335ms以上，最大QPS可达到140左右，与预期的350的QPS相差甚远；也就是说结果完全不能符合要求。
开始寻找原因，首先查了一下SQL的耗时。
读取db的时间为：4ms 这个时间包含网络传输和字段映射的时间
这个并不是瓶颈，然后开始排查是不是代码逻辑耗时特别长。
处理的时间：0 这个说明代码处理时间可以忽略不计了。
最后只能怀疑是缓存耗时过长了
在cat上看数据如下：
image.png
读一次缓存大约需要1.6ms,这个完全是不能够接受了，因为特效厅这个每次大约200个ID我需要读200次缓存，也就是说缓存获取需要200*1.6ms=360ms,到此可以发现瓶颈在缓存这块。再看一下线上取缓存的耗时：
image.png
线上的缓存每次耗时约为0.2ms,这是不是说明测试缓存的squirrel延时比较严重呢？咨询一下squirrel的同学，认为是跨机房了。我们的测试机是在大兴，squirrel的测试机器是在永丰看一下网络延时：
image.png
image.png
可以看到垮机房确实有1ms的延时，squirrel同学说test环境没有资源，只能垮机房，好了到此我们认为是，线下环境跨机房导致，缓存获取时间过长，那线上是不是不会出现这种情况呢？我们改到线上压测。
看一下线上压测的效果：
image.png
结果发现比线下效果更差，看了一下cat的时间，也是比线下更长，说明线上取缓存耗时也比较长。再次咨询squirrel同学，让他帮我查了一下线上的key的耗时，反馈说是1ms以内。squirrel同学反馈说我们的路由策略是有问题的，路由策略是默认的， 默认的路由策略是只读主节点。 这个集群的主节点在 大兴。 所以yf 的就是跨机房读，应该改为把路由策略改成 master-slave，看了一下效果确实能好一点，但是这个还不是瓶颈。看了squirrel的api有批量操作的方法，咨询了squirrel同学这个效率比循环获取会高多少？目前他们还没有数据支撑，只是说批量的操作会减少io，如果可以从200io减少到1一次io，那么这样的话效率也应该能提高不少。
3 针对压测的优化
好了，优化其实还是很简单的，就是把之前的循环存放key的操作改为，批量存放key的操作，squirrel的文档写得还是很不错的http://squirrel.sankuai.com/doc/index.html，改好之后再做一次压测。
image.png
可以看到效果很明显，说明之前的瓶颈应该是在 第一：网络io,第二：跨机房网络延时。
在看一下cat每次获取缓存耗时：
image.png
一次200个耗时6ms左右效果还是很不错的，比循环200次好了大约40倍。
网友评论