全栈性能测试修炼宝典（全栈性能测试修炼宝典第二版pdf）

背景 #

这个事情也是最近做的，因为上线nginx被我换成了openresty，然后接入层服务也做了大改动，虽然我们app（internal office）的并发性不高，但还是压力测试比较好，上线的时候稳定多了一点。

所以用jmeter来看看简单的压力测试，并记录在这里。

这一次，我也找到了几个可以按的接口：登录界面，登录后获取用户信息的界面，登录后写入数据的界面。

因为这些接口，在Postman中，我懒得手动输入jmeter（那种表单，懒得一一获取），唯一需要解决的就是，能不能在postman中导出请求，然后导入到jmeter中。

邮递员请求导入 jmeter#邮递员导出#

简单来说，如果请求在 Postman 中不可用，您还可以使用数据包捕获（Charles、Fiddler）将请求导出为 Charles 中的 curl 格式，然后将其导入 Postman。

邮递员导入 jmeter 的方式也比较简单，网上有人写了一个开源库来做这件事。

先出口：

你最终会得到一个 json 文件。

将json文件转换为jmeter的jmx#

使用一个开源库，也是用 Java 编写的：

当我使用它时，因为我在 postman 中有一个请求有点问题，它会导致报告一个空指针，然后我自己调试它，它就解决了，所以你也可以拉我的存储库：

顺便说一句，我还对原来的仓库做了一个公关。

如何使用：

Copy$ git clone https://github.com/Loadium/postman2jmx.git
$ cd postman2jmx
$ mvn package
$ cd target/Postman2Jmx
$ java -jar Postman2Jmx.jar my_postman_collection.json my_jmx_file.jmx

通常，你最终会得到一个 my_jmx_file.jmx 文件，只需导入 jmeter。

jmeter config # 导入效果 #

打开这个jmx后，我做了一点修改，增加了查看结果的数量，修改了线程组的配置，大致如下：

我的项目仍然依赖于 cookie 机制，所以我在这里使用 cookie 管理器，它会自动将 set-cookie 存储在线程的返回 cookie 区域，后续请求也会自动携带：

如果您不知道，可以单击此页面上的“帮助”以查看帮助文档。

导入的效果还是相当不错的：

设置线程组中的并发线程数#

一般来说，对于压力测试，我们会关注某个接口的QPS或TPS，一般会添加一个监听器，比如聚合报表，来检查最终接口的吞吐量（TPS）

我们一般使用 jmeter 进行压力测试的目的是，我需要对接口的极限是什么进行压力测试，以及在当前的架构和环境中可以达到多少笔画/秒。我得到了限制 TPS。

当然，我们也可能在一定程度上增加压力，发现接口的TPS符合标准，所以我们不在乎，也不会继续加压，在增加的压力下寻找TPS拐点。

但是，我之前一直有一个问题，那就是不知道如何设置jmeter中的并发线程数，经过检查，我发现在性能测试领域，业界普遍称这个值为VU（虚拟用户）。

在制定测试计划时，性能测试人员会先根据系统的大小和系统的峰值时间进行估算，总体来说还是有点复杂的。我在这里也看了一本书，全栈性能测试修炼书，其中第7章讲到了如何计算。

我也在网上简单查了一下，比如：

Copy通用公式
对绝大多数场景，我们用：
并发量=(用户总量/统计时间)*影响因子（一般为3）来进行估算。
　#用户总量和统计时间使用2/8原则计算，即80%的用户集中在20%的时间
　#影响因子，一般为3，根据实际情况来
　#通用公式使用了二八原则，计算的并发量即是峰值并发量。
例子
以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据2/8原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3小时*60*60s）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！　

在地铁示例中，对于并发用户，应将其设置为 12

然后，文章中的另一个例子，它是根据PV计算的：

Copy根据PV计算
并发量=(日PV/统计时间)*影响因子（一般为3）
　#日PV和统计时间使用2/8原则计算，即80%的用户集中在20%的时间
　#影响因子，一般为3，根据实际情况来
　#PV公式使用了二八原则，计算的并发量即是峰值并发量。
 
例子
比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w，pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：1000w*80%/(9*60*60)=246.92个/s,取经验因子3，则并发量应为：246.92*3=740

所以，说到底并发用户数不是很高，在一般的系统中，感觉jmeter中的并发线程数足以控制在500个以内，如果不行，在1000个以内就足够了。如果超过1000，看看是否应该考虑使用多个jmeter实例进行分布式压力测试，因为一般对于大公司这样的大企业来说，压力测试都是分布式压力测试，压力测试机集群从几十个单元开始。

当然，如果你必须拼命增加单个 jmeter 实例（即 java 进程）中的线程数，你可以查看以下文章：

我们看看如何增加堆大小之类的，将线程数增加到 10,000 个线程，但无论如何我不推荐，毕竟机器一般只有几个核心或几十个核心，打开这么多线程会导致频繁的线程切换。

线程组中其他属性的设置#

以下图为例：

300 个线程，但 Rapp-up 周期是 300s，这意味着我的 300 个线程将在 300s 内启动，即 1s 将增加 1;如果设置为 1,300 个线程会在 1 秒内启动，而且我觉得对电脑的影响比较大，所以还是温和一点比较好。

循环计数我在这里设置为无限，那么，整个脚本就是一直在运行，当然不是，你可以看到，我在上图中将持续时间设置为 600s，也就是说，脚本总共运行了 10 分钟。

可以预测的是：

在前 300 秒中，它从 1 个线程逐渐增加到 300 个线程;在接下来的 300 秒内，300 个线程同时运行脚本，此时的压力是稳定的 300 个虚拟用户或并发产生的 300 个线程。

jmeter 运行 #

当我们进行严格的压力测试时，我们通常不会在 GUI 中运行它，而是使用 CLI 方法。

例如，使用 CLI 在 Windows 下进行压力测试

CopyF:\apache-jmeter-5.2.1\bin>jmeter -n -t Test.jmx -l result.jtl -j test.log

或者在 linux 下进行压力测试：

Copy./jmeter -n -t Test.jmx -l result.jtl
长时间压测
nohup ./jmeter -n -t Test.jmx -l result.jtl 2>&1 &  

压力测试时，输出如下：

Copysummary =   3801 in 00:00:40 =   94.5/s Avg:   417 Min:    13 Max:  3817 Err:     0 (0.00%)
表示现在是压测开始后的第40s，3801是总共发出去的请求，94.5/s是这期间的tps，后面就是平均数、最小、最大、错误数

过了一会儿，会有一连串的这样：

Copysummary +   2590 in 00:00:35 =   74.3/s Avg:  1076 Min:    97 Max:  9799 Err:     0 (0.00%) Active: 151 Started: 151 Finished: 0
summary =   6391 in 00:01:15 =   85.1/s Avg:   684 Min:    13 Max:  9799 Err:     0 (0.00%)

这

+ 行表示增量，距离上一行结束已经过去了 35 秒，这 35 秒内生成了 2590 个请求，该时间段的 TPS 为 74.3

“=”的行是脚本开头到现在为止的总指标，比如请求数6391，也就是40秒的请求数3801+增量2590

顺便说一句，这次上线之前，为了测试稳定性，我按了18个小时：

另外，后面的活跃线程数，我用了200个并发18小时，第二天，我发现系统还是挺稳定的。