背景#

这个事情也是最近做的，因为线上nginx被我换成了openresty，然后接入层服务也做了较大改动，虽然我们这个app（内部办公类）并发不算高，但好歹还是压测一下，上线时心里也稳一点。

于是用jmeter简单压测下看看，这里记录一下。

这次也就找了几个接口来压：登录接口、登录后获取用户信息接口、登录后写数据的一个接口。

因为这几个接口，在postman里面有，我就懒得手工录入到jmeter了（那种form表单，懒得一个一个弄），唯一需要解决的就是，能不能把postman里面的请求导出，然后导入到jmeter里面。

postman请求导入jmeter#

postman导出#

简单提一句，如果请求在postman里没有，也可以用抓包方式（charles、fiddler），在charles里将请求导出为curl格式，然后导入到postman里面。

postman导入jmeter的方式也比较简单，网上有人写了个开源库来做这个事情。

先导出：

最终会得到一个json文件。

转换json文件为jmeter的jmx#

使用了开源库，也是java写的：

https://github.com/Loadium/postman2jmx

我用的时候，因为我postman里面有个请求有点问题，导致报了空指针，然后自己debug了下，解决了，所以大家可以拉我的仓库也行：

https://github.com/cctvckl/postman2jmx

我也顺便给原仓库提了个pr。

使用方式：

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配置#

导入效果#

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

我这边项目还是依赖cookie 机制的，所以我这边就用了cookie manager，它会自动把返回中的set-cookie，存储到该线程的cookie区域，后续的请求也会自动携带：

如果不了解，可以在该页面点击Help，就能看到帮助文档。

导入的效果还是挺好的：

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

一般来说，压测的话，我们会关注某个接口的qps或tps，此时一般要增加一个listener，如聚合报告，来查看最终接口的吞吐(tps)：

我们一般用jmeter做压测的目的，是我需要压测出，在目前架构、环境下，该接口的极限是多少，能达到多少笔/s，此时，就是靠不断地加压（比如提高并发用户数），在压力越来越大的情况下，系统一开始可能Throughput的值是一路增加的，但慢慢地，会到达一个拐点，到了这个点，你再加压，Throughout也不会继续增加了，此时，就拿到了极限tps。

当然，我们也可能加压到一定程度，发现接口的tps达标了，就不管了，不会继续加压，去寻找那个压力不断提升下的tps拐点。

但是，我之前一直有个问题，就是不知道jmeter里的并发线程数怎么设置，经过查阅，发现在性能测试领域，业内一般把这个值叫做 VU（virtual user）。

这个值，性能测试人员在做测试计划的时候，就会先去根据系统的使用人员规模、系统的高峰时间有多长，来进行估算，总的来说，还是有点复杂。我这边也是看了一本书，全栈性能测试修炼宝典，里面第7章讲了具体怎么算。

我这边也网上简单查了下，比如：

https://www.cnblogs.com/gltou/p/15168252.html

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进程）提升线程数，可以看看下面这篇文章：

https://www.blazemeter.com/blog/jmeter-maximum-concurrent-users

看看是如何靠增加堆大小之类，来提升到10000个线程的，不过我反正是不建议，毕竟机器一般也才几核、几十核为主，开那么多线程会导致频繁的线程切换。

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

以下图为例：

300个线程，但是Ramp-up period 是300s，意思是在300s内将我那300个线程启动起来，也就是1s增加1个；如果你设为1的话，300个线程就会在1s内启动，我感觉对电脑冲击比较大，还是平缓一点好。

Loop count我这里是设置为无限，那，难道整个脚本就一直跑吗，当然不是，可以看到，我上图设置了Duration为600s，也就是说，脚本总共跑10分钟。

可以预测的是：

在前300s，会逐步从1个线程增加到300个线程；在后面300s，就是300个线程同时去跑脚本，这时候的压力是稳定的300 virtual user或者说300线程产生的并发。

jmeter运行#

严格压测时，我们一般不在GUI里面去运行，而是采用cli方式。

比如，在windows下用cli方式压测：

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%)

为+的那一行，表示的是增量，从上一行结束后，过去了35s，这35s期间产生了2590个请求，这期间的tps是74.3

为=的那一行，就是从脚本开始到目前为止，总的指标，如6391这个请求数，就是40s时候的请求数3801 + 增量的2590.

顺便给大家看下，我这次上线前，为了测试下稳定性，压了18个小时：

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