每一个公司都有一个得罪不起的性能僧

作为一个仍在经验积累初期的性能测试小白,做过的项目屈指可数,每次做一个测试任务,都是边做边摸索边学习的过程。这次是为某项目测了一些重要的接口,服务框架用的是spring boot,数据库是mongodb和mysql,框架数据库均是第一次遇到。此次测试的目的是在达到测试指标时,接口能承载的最大并发数,对性能差的接口进行优化。测试的指标是响应时间≤100ms(本文提到的响应时间均为90%响应时间),tps在基准测试下≥10,CPU使用≤80%,内存使用≤75%。

其中一个任务管理页面查询的接口,基准测试通过,并发用户50路压测下,响应时间109ms,TPS是989.9。

由于这个任务管理页面查询接口调用了另外四个查询接口,为了定位到消耗时间的具体环节,让开发人员在接口网关脚本中做处理,压测时通过网关日志打印出每个接口调用时花费的时间,可以看到绝大部分响应时间都花在t4上。

t4这个接口会对mongodb数据库进行查询,但是此collection中仅有2000条数据,对mongodb来说数据量并不大,从响应时间来看接口性能较差,不优化的话会影响系统性能测试,因此直接对这个接口进行测试,查找响应时间较高的原因。

20路并发下,t4接口的响应时间已达到111ms。此接口逻辑并不复杂,仅是一个简单的mongodb查询,数据量也不大,为什么这么慢呢?查看mongodb这个collection并未建索引,另查询mongodb慢日志中有一个group查询语句最慢时已有136ms。

通过代码查看该mongo原查询语句实现方法如下所示:

在日志中同样给出提示,这个分组查询的命令已经被弃用了,并给出了mongo官网地址:2017-12-02T13:37:10.711+0800W COMMAND [conn747] The group command isdeprecated. See http://dochub.mongodb.org/core/group-command-deprecation。

另外,考虑到生产环境中这个collection下的数据量会较大,建议开发增加索引。在建索引和优化了group查询语句后再次对t4接口进行50路并发的压测,由下面测试结果可见,响应时间从原来的111ms下降到12ms,tps较优化前也提升了5倍多。

优化了t4接口之后,再对原任务管理页面查询的接口进行测试,100路并发下,响应时间=68ms,tps=2034.8/s,与优化前50路并发测试结果相比,优化效果明显。

借助mongodb自带的监控工具、慢日志分析和开发人员的协助,这次问题定位还是比较顺利的。通过优化前后测试结果对比可见,仅仅修改一个查询方法就让接口响应速度提升将近10倍。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20171225G04VZY00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券