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

作为一个仍在经验积累初期的性能测试小白，做过的项目屈指可数，每次做一个测试任务，都是边做边摸索边学习的过程。这次是为某项目测了一些重要的接口，服务框架用的是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倍。