外卖业务服务器端性能测试总结

 

指标	压测改善前	压测改善后	结论
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带宽无限制，使用集团网络，预测会有限流)；

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

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

• 测试时间：一周

测试环境搭建

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

性能工具的引入

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

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

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

测试的执行

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

软件硬件配置调整与优化

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

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

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

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

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

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

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

1. 网关配置有误，导致限流的发生

1. 对接的ERP方代码有误

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

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

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

总结

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

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