Jmeter之单接口的性能测试

前言：

  服务端的整体性能测试是一个非常复杂的概念，包含生成虚拟用户，模拟并发，分析性能结果等各种技术，期间可能还要解决设计场景、缓存影响、第三方接口mock、IP限制等问题。如何用有限的测试机器，在测试环境中模拟并评估生产环境的真实性能状态，找出性能瓶颈，也一直是性能测试工程的核心目标。

但一个大型系统的性能，也是由一个一个接口的性能来保证的，同样遵循木桶原理，即性能最差的那个接口将会拉低整个系统的性能，因此评估单个接口的性能，对于优化接口的性能，保证系统的整体性能，也一样很有必要，量变终会引发质变。而且相对来说实现简单，对于那些不熟悉性能测试工程的同学也是了解性能测试的一个很好的切入点。

性能指标

一般系统性能水平都是通过吞吐量来体现，而系统吞吐量有以下几个重要指标：

QPS（TPS）：每秒钟request/事务 数量
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间

同时CPU运算、IO、外部系统响应等因素也会直接影响这些指标，这里我们选择了QPS(TPS)，响应时间，CPU占用率，内存占用率四个指标分别来评估单个接口的性能。而对于并发数，则可以通过 并发数= QPS*平均响应时间 计算得出结果。

测试工具选择

性能测试几乎已经断绝了手工测试的可能，选择一款合适的测试工具很有必要。目前业界性能测试工具相当多，综合需求目标、成本控制、扩展性、生命力等等因素考虑选择，这里我只列了主流的三种：

loadrunner 大概是生命力最强的性能测试工具了，学习资料也相对较多，只是体型有点大，环境安装麻烦。

Jmeter 基于java编写，GUI配置管理接口，入门简单，方便快速开展性能测试工作，还支持插件扩展。

Locust 是python下的一个性能测试工具，优点是通过代码编写压测脚本，扩展性强，适合全自动化，同时利用了协程的概念，支持单机高并发。

由于我们只是对单个接口进行压测，太复杂的环境与较高的学习成本都不利于快速开展工作，因此我选择了jmeter，当然也只是对jmeter的简单使用，并不意味着jmeter功能不够强大。

Jmeter 获取性能指标

安装Jmeter

这并不是一篇讲Jmeter的文章，因此关于Jmeter的下载安装就不再赘述，但有几个非常好用的Jmeter 插件还是推荐可以安装一下的：

Transactions per Second（监听TPS）
Response Times Over Time(监听响应时间)
PerfMon Metrics Collector（监听服务器CPU、内存）

编辑接口信息

1.开启一个线程组

2.线程组中添加一个http请求

3.编辑接口信息，如果需要参数较多，可能还需要进行参数化。

设置监听器

1.右键线程组，设置监听器

2.添加察看结果树

3.添加聚合报告

4.添加安装的监听插件

1.对于PerfMon Metrics Collector插件，我们需要在服务器中运行Jmeter提供的一个简单的web服务器配合使用。

2.设置监听器的同时，也可以保存数据到本地csv文件

开始监控

1.设置线程数（一开始不设置太高）

2.设置达到最大线程数的时间

3.点击运行

收集监控数据

运行结束后，就可以在对应的监听器中查看获取的数据了。把这些结果统计整理

数据指标分析

通过上面我们设置的监听器，我们应该能得到TPS、响应时间、CPU、内存这些指标了。当然这些指标也只是简单的评测某一接口的性能区间。

这里有一些计算方法

QPS计算方法:

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间

公式：( 总PV数 80% ) / ( 每天秒数  20% ) = 峰值时间每秒请求数(QPS)

机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器

如：每天300w PV 的在单台机器上，这台机器需要多少QPS？

答：( 3000000  0.8 ) / (86400  0.2 ) = 139 (QPS)

如果一台机器的QPS是58，需要几台机器来支持？

答：139 / 58 = 3

通过这些公式计算，我们应该能整理出来一份相对专业的测试报告了。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！