指标	压测改善前	压测改善后	结论
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，需要同时跑网关、外卖等多服务，且此时并未分多节点，系统压力较大；而是代码中存在大量待优化的地方，总结如下：

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

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

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

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

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

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

对接的ERP方代码有误

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

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

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

总结

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

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

外卖业务服务器端性能测试总结相关推荐

性能测试总结(三)--工具选型篇
性能测试总结(三)--工具选型篇本篇文章主要简单总结下性能测试工具的原理以及如何选型.性能测试和功能测试不同,性能测试的执行是基本功能的重复和并发,需要模拟多用户,在性能测试执行时需要监控指标参数, ...
财务软件性能测试要求,财务报表性能测试总结 - 泊涯 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园...
'MZ5KM"Ri"lg"xl8i0 财务报表性能测试总结;W:]k4[o6i,l!{D0 Q:s|]PdZ$l0 好久没写博客了, ...
单日2000W+订单，如何忙中不错？美团外卖业务异常检测实践详解
美团外卖从 2013~2018,历时五年,现在已经是全球最大外卖交易平台.目前单日完成订单两千多万单,交易频次高,如果不能及时发现潜在业务指标异常,有可能引发重大事故. 写在前面外卖业务持续高速成长 ...
美团半年财报出炉，外卖业务增长背后鲜为人知的秘密
9 月27 日,美团点评发布了上市后的首份财报:截至6月30日,美团点评上半年总收入达263 亿元,同比增长 91.2%:毛利润61 亿元,同比增长13%:净亏损288 亿元人民币,经调整亏损净额为4 ...
性能测试总结（performance testing）（一）
1.为什么要做性能测试? 1)目前绝大多数应用都是基于网络的分布式应用,我们无法知道用户数量,用户场景的不确定性,导致系统测试时,不仅仅是功能,业务逻辑,接口测试,还要测试系统性能.一个用户没问题,但 ...
性能测试总结(一)---基础理论篇
随着软件行业的快速发展,现代的软件系统越来越复杂,功能越来越多,测试人员除了需要保证基本的功能测试质量,性能也随越来越受到人们的关注.但是一提到性能测试,很多人就直接连想到Loadrunner.认为L ...
性能测试总结(二)---测试流程篇
本文主要介绍下性能测试的基本流程,性能测试从实际执行层面来看,测试的过程一般分为这么几个阶段,如下图: 下面分别介绍下每个阶段具体需要做什么: 一.性能需求分析: 性能需求分析是整个性能测试工作开展的 ...
性能测试总结(一)---基础理论篇（转载）
随着软件行业的快速发展,现代的软件系统越来越复杂,功能越来越多,测试人员除了需要保证基本的功能测试质量,性能也随越来越受到人们的关注.但是一提到性能测试,很多人就直接连想到Loadrunner.认为L ...
服务器端性能的关键指标,应用服务器性能评价关键指标
应用服务器性能评价关键指标内容精选换一换 SAPS(SAP Application Performance Standard)值是一种独立于硬件的度量单位,用于描述SAP环境中系统配置的性能,是S ...

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