如何做性能、压力测试

本期，讨论一下如何做性能、压力测试。

性能、压力测试的目的，除了作为上线或交付前的重要报告，更重要的是 ：通过测试可以知道当前系统性能极限。

以一个商城系统为例，经过测试后，就能知道1小时1亿交易额的高压力场景是否能承受。

需要提前说明的是，性能测试一般只针对后端接口测试即可，页面测试一般只需要在压测过程中手动打开看一下慢不慢、正不正常即可。

性能测试一般按以下4个步骤进行 ：

圈定测试范围

明确性能指标

执行测试

分析结果

圈定测试范围
虽然网站系统是一个整体， 但是一次性评估整个网站系统的性能往往是难以实现的，所以需要在测试前圈定测试范围。

性能测试一般是以一个业务板块或者一个业务场景为单位的，例如，一整个网站系统有博客、商城、直播、点播等业务板块。 那么，应该单独对每个业务板块进行性能测试，因为每个业务板块的压力并不是平均的，自然性能要求也就不一样。

选定了一个业务板块后，需要挑出重点或调用概率较高的接口， 最好能覆盖该业务板块下的所有数据表。

挑选出重点接口进行测试 ，主要是为了简化测试 ，因为业务板块的功能一般是比较庞大的 ，几百个接口是常有的事情。

另外，虽热面面具到地测试所有接口是最好的，但是由于成本等因素，性能测试往往只需要保证主体功能的性能即可，至于一些边缘功能，即使性能有问题，也不会对大多数用户造成影响。

明确性能指标
明确性能指标无非就是明确吞吐量、并发量、响应时间、错误率。

根据上一期《性能指标》的换算方法，100万用户峰值在线用户量为10万， 峰值并发量为1万，平均响应时间要求趋近500毫秒，吞吐量要求高于2万RPS ，错误率要求低于0.5%。

这里的目标值最好根据行业数据或历史数据作调整，因为这样的性能目标值其实已经相当高。以商品下单为例：这样的性能指标下，每单即使是1块钱，1小时的交易额已趋近7200万，100万用户已平均花费7.2万。

这里需要注意的是：即使是同一个业务板块， 不同接口的实际压力也是存在差异的。 例如，查询商品接口的请求压力远高于下单商品的接口。

不过，为了简化性能测试 ，我们一般只要求查询接口满足目标性能指标 。至于更新、新增接口只需要满足目标性能的1/2即可。 当然，根据实际情况，部分接口的性能要求可以更低。

一些情况下，生产环境是不允许性能测试的， 那么可以使用缩水版的测试环境、开发环境进行测试，但相对应的，性能指标也需要降一下 。

执行测试
明确了测试目标后就可以进行测试了， 测试工具我们推荐使用JMeter，当然其他测试工具或者公有云的压测服务也是可以的。

测试环境最好是内网环境 ，最好在测试前先测试一下网络延迟（包括内网环境）。

一般情况下，吞吐量、响应时间、错误率是测试的结果。 而并发量是测试的压力 ，如果并发量为1000 ，则需要设定测试工具启动1000个线程同时发送请求。

一些测试工具是可以设置并发量和在线用户量的，如果没有在线用户量的设置 ，只设置并发量即可。

另外，测试时，测试工具需要梯度提升并发量压力， 如从100、500、1000、2000、5000的梯度上升。这样，除了能模拟真实情况的压力提升过程，也可以让服务器充分预热， 避免出现不具备参考意义的测试结果。

但是这只是针对普通情况，如果是限时活动、抢购等场景则不能让压力梯度上升， 因为此类场景的压力就是断崖式上升的，应该尽量模拟真实情况。

至于测试的时间，如果是压力、性能测试 ，每个接口都需要单独测试 ，也可以根据业务场景组成接口作为一个测试单元， 每个测试单元的峰值压力需要保持5分钟以上。

如果是稳定性测试 ，则按比例随机调用接口 ，并保持峰值压力2小时以上， 条件允许的话 ，我们更推荐24小时。

如果是极限测试 ，我们推荐的做法是 ：在目标并发量后仍然继续提高并发量 ，且每个并发量需要保持1分钟以上， 直到平均响应时间高于2秒或错误率高于1% ，则此并发量可视为极限压力。

另外，性能测试结果与数据量一般是相关联的 ，所以性能测试时 ，需要往数据库填充一定的数据量， 一般的填充量为1万行、10万行、100万行、500万行等。 根据预测、历史数据填充相近的数据量即可。

性能测试期间 ，每台服务器的物理资源使用情况也需要记录 。如最大CPU、内存、带宽使用率等 。

在峰值压力下，这些物理资源的使用率一般要求在80%以下，这是为了预留一些压力空间，另外现在的服务器一般是虚机或容器，一些时候物理资源的上限实际是不足面版值的。性能测试期间，不要忘了手动打开页面或操作APP 看一下功能是否正常、响应是否缓慢。

分析结果
测试结果应该由2部分组成，只有这两个都达标，才算满足性能。

一是压测的结果，性能指标的测试结果；

二是测试过程中，服务器的附载情况。

总结
性能测试可量化系统的性能，结合业务增长预测，即可提前扩展好服务器，而非出现明显缓慢或各种崩溃时再手忙脚乱地扩展。