外卖聚合服务性能测试总结

代码质量过关，性能测试就只是走个过场。

上周对目前开发的外卖聚合服务进行了一周的负载及压力测试，收获了一些经验，也积攒了一些教训，和团队中的小伙伴们一起对一款互联网产品上线前的压力测试有了系统的了解与实践，在这里分享一下心得，也借此感谢小伙伴们跟我一起破了连续加班9天的最长记录，如果“有幸”被领导看到，记得给我们加个鸡腿儿，哈哈。
既然要求加鸡腿儿，那就得先用成果来说话。

指标	压测改善前	压测改善后	结论
TPS	50/s~70/s	350/s~380/s	可支持一秒内300人同时下单
平均响应时间	5s	0.2s	远远低于饿了么要求的3s响应时间

这个结果，着实让小伙伴们颇为兴奋了一阵子，不过天天看《甄嬛传》宫心斗的我，必须适时地泼一下冷水：压测改善后性能提升的有多高，就说明你们当初写的代码有多烂。。。

话虽这么说，一个团队中人员经验有高低，习惯有好坏，代码质量难免参差不齐，所以做好压力测试，一来可以提高产品质量，二来可以帮助大家发现开发中的问题，还是非常重要的。所以随着测试技术的发展，许多公司也单独把性能测试独立出来，建立专门的性能测试小组或团队，在实施的过程中建立独立的流程与规范。反思我们一个月前的那次压力测试，在性能需求模糊的情况下，随便找了一个性能测试工具就开始进行性能测试了，在这种情况下得到的性能测试结果自然很难体现系统真实的能力，与系统真实的性能也相距甚远。
这次我们的测试规范了流程，具体如下：

性能需求分析

性能需求分析是整个性能测试工作开展的基础。在这个阶段要确定测试的目标和范围。测试目标应该借助于有行业经验的开发人员、领导的经验，按照客户的要求来定；测试范围则主要分析系统的功能模块进行调研与分析。
作为外卖聚合服务，本项目的：

• 测试目标：能够支撑订餐高峰期的并发量。根据百度对“大客户”的定义（单店日订单量大于1000），根- 据外卖数据分析，订单高峰为中午和晚上的2个小时，即平均每分钟为1000/2/60=8单，若按100家店来计算，平均每秒钟为8*100/60≈14单。

• 测试范围：高频且对并发有要求的接口有两类：输入：美团和饿了么的推单接口；输入：由聚合服务向ERP推单的接口。

性能测试计划

确定性能测试的需求之后，就要制定性能测试计划。测试计划的大概内容包括：

• 项目的简单背景描述：支撑客户外卖业务，保持订单高峰期服务的稳定性，提升服务性能的极限；

• 本次性能测试的需求与目的：参照性能需求分析；

• 测试环境的准备：使用阿里云ECS(1核8G，SLB带宽无限制，使用集团网络，预测会有限流)；

• 测试数据的准备：编写测试脚本

• 人员配置：开发人员、运维人员、需求人员

• 测试时间：一周

• 测试环境搭建

• 测试环境搭建分硬件环境和软件环境，由于我们用的是阿里云服务，所以硬件环境无需搭建，软件环境建议画出大致的系统架构图，作为性能测试人员，需要对系统中的每个部分有深入的了解，因为性能测试的分析并不是死盯着系统应用那一层，中间件、数据库、系统、硬件都有可能成为系统的瓶颈。O2O的大致架构图如下（刚买了wecom的数位板，请原谅我粗鄙的画风）：
  

性能工具的引入

工具的引入分为自行开发与引入市面上的现有工具。市面上的现有工具又分为收费与开源免费，各有各的优缺点。我们要做的是对需求进行分析，从成本，购买成本，开发成本，现有开源工具的二次开发成本，人员学习使用成本以及时间成本等。

在这里再强调一点，不是只有压力测试工具属于性能工具，在性能测试过程中所用到的工具都属于性能工具，如测试数据生成工具，性能监控工具等。

工具的选择上，我们使用了LoadRunner、jProfiler和nmon这三款工具。LoadRunner用来进行负载和压力测试，jProfiler用来进行性能分析，nmon用来监控系统负载。

测试的执行

测试的执行要根据选择的工具、测试的功能和开发的脚本来进行。我们使用LoadRunner创建虚拟用户，从1到1000都，运行时间从10分钟到1天，都进行了测试。

软件硬件配置调整与优化

如同文章开头说的，如果代码写的好，性能测试不过是走走过场，这时就应该出测试报告了。反观我们的代码，需要优化的地方就很多了。首先上两张测试初期的截图：

从图中可以发现，tps仅为19/s，且存在大量报错，响应时间也在0.5s左右，甚至会超过3s；cpu和内存的占用接近100%。出现这种情况的原因有两方面，一是目前服务器的配置确实偏弱，1核8G，需要同时跑网关、外卖等多服务，且此时并未分多节点，系统压力较大；而是代码中存在大量待优化的地方，总结如下：

• 代码中存在大量数据库连接使用未关闭的情况，导致后续事务无法获取数据库连接；

• logstach配置错误，导致Redis数据无法及时导出，2G的存储量很快就会被占满报错；

• MQ队列使用错误，为每次事务单独建立了队列，且这些队列无法自动清除；

• 日志级别为info，导致CPU很大一部分的是用来处理日志相关的功能；

• 数据库配置错误，导致性能缓慢

• 网关配置有误，导致限流的发生
  -对接的ERP方代码有误

此处，系统的架构图作用就很明显了，在日志报错信息不明确的情况下，可以查看每部分的监控信息，查出报错原因；如果没有架构图，则只能东一榔锤西一棒头，效率很低。

经过对上述问题的修复，且将ECS升级为2核16G，三节点之后，tps达到了380/s，提升了接近20倍（对外可以吹牛皮，对内实在是汗颜），响应时间也控制在了0.1s左右。

系统的调优是个循环的过程，在我们的实际操作中，往往是改善完一点就再测试一次，再次寻找下一个导致问题的点。虽然测试调优的过程很枯燥，但每一次数字的提升总是能让我们兴奋。

总结

这是一次成功的性能测试，但在测试调优中占用了不少的人力和时间，去改善因为代码的不足出现的问题，对项目的成本和进度来说，是一次失败。代码质量的问题在项目之初就应该考虑到，当初如果做好代码审查工作，那么性能测试的时间能够缩短一半。这也是这次性能测试最大的教训。

在这里衷心的希望我们的代码质量越来越好，让以后的压力测试仅仅是走个过场而已。