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

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

上周对目前开发的外卖聚合服务进行了一周的负载及压力测试，收获了一些经验，也积攒了一些教训，和团队中的小伙伴们一块儿对一款互联网产品上线前的压力测试有了系统的了解与实践，在这里分享一下心得，也借此感谢小伙伴们跟我一块儿破了连续加班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左右。

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

总结

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

在这里衷心的但愿咱们的代码质量愈来愈好，让之后的压力测试仅仅是走个过场而已。