http压测工具 jmeter 安装配置

压测相关术语
响应时间(RT) ：指系统对请求作出响应的时间.
吞吐量(Throughput) ：指系统在单位时间内处理请求的数量
QPS每秒查询率(Query Per Second) ：“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS(TransactionPerSecond)：每秒钟系统能够处理的交易或事务的数量
并发连接数：某个时刻服务器所接受的请求总数 .

 

1、QPS（Queries Per Second）

概念：服务器每秒处理查询次数，是一台服务器每秒能够处理的查询次数。用户发起查询请求到服务器做出响应这算一次，一秒内用户完成了50次查询请求，那此时服务器QPS就是50。

2、TPS （Transactions Per Second）

概念：服务器每秒处理的事务数，一个事物是用户发起查询请求到服务器做出响应这算一次。纳尼？这难道不是QPS的概念吗？划重点，这里就要说清楚一个概念了，在针对单接口，TPS可以认为是等价于QPS的，如访问 ‘order.html’ 这个页面而言,是一个TPS。而访问 ‘order.html’ 页面可能请求了3此服务器（如调用了css、js、order接口），这实际就算产生了三个QPS

所以，总结下就是，在针对单接口的时候TPS = QPS ,否则QPS就要看实际的请求次数了。

2、RT（Res（onse Time）

概念：响应实际，就是从客户端请求发起到服务器响应结果的时间。RT这个参数是系统最重要的指标之一，它的大小直接反应了当前系统的响应状态。基本和咱们用户体验息息相关，现在好一点监控系统一般都有三个RT，即平均、最大、最小。

一般系统RT 100ms 以内是比较正常的，300ms 勉强可以接受，1s的话再加上一些其他的外因，给用户的体验就是实实在在的不爽了。

3、并发数

概念：系统能同时处理的请求的数量，很多人经常会把并发数和TPS理解混淆。举例，请求一个index.html 页面，客户端发起了三个请求（css、js、index接口）,那么此时TPS =1 、QPS =3 、并发数 3。

SO，计算公式 ： QPS=并发数/RT || 并发数=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的用户访问量，吞吐量（系统能承受多少压力）和当前请求对CPU消耗、内存、IO使用等等紧密相关。单个请求消耗越高，系统吞吐量越低，反之越高。

一个系统的吞吐量和其TPS 、QPS、并发数息息相关，每个系统针对这些值都有一个相对极限值，只要其中某一个达到最大，系统的吞吐量也就到达极限了。如此时压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，各种资源切换等等的消耗导致系统性能下降。

关系：

所以，理解上面几个关系后，就可以推算出：

QPS（TPS）= 并发数/平均响应时间

5、PV（Page View）

概念： 即每个页面的浏览次数，用户每次刷新就算一次。

6、UV（Unique Visitor）

概念：独立访客数，每天访问的用户数，此数据需要根据用户唯一标识进行去重。

7、Load（系统负载）

概念：此数据指的是Linux系统的负载情况，也就是咱们平时所用Top命令时，最上面显示的数据信息( load average: 0.1, 0.2, 0.5)。此时会显示1分钟、5分钟、15分钟的系统平均Load，很显然load average 的值越低，你的系统负荷越小。

简单的说下这个值应该怎么看，如果你是单核cpu,那此值为1的时候就是系统已经满负荷状态了，需要你马上去解决。但实际经验告诉我们，当系统负荷持续大于0.7的时候（也就是70%），就需要你马上来解决问题了，防止进一步恶化。

为什么需要三个值 load average: 0.1, 0.2, 0.5，其实就是给你个参考。比如只有1分钟的是1，其他俩都是0.1，这表明只是临时突发的现象，问题不大。如果15分钟内，系统负荷都是1或大于1，那表明问题持续存在啊。所以你应该主要观察15分钟的系统负荷。

 

Throughput 和TPS 区别

 

吞吐量：
吞吐量是指单位时间内系统能够完成的工作量，它衡量的是软件系统服务器的处理能力，就是在一秒中统计所完成的工作量。

一个系统的吞度量（承压能力）与请求对CPU的消耗、外部接口、IO等等紧密关联。单个请求对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

TPS（每秒事务数）:
TPS是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

联系：

都是性能指标，都是以秒为单位进行计算

区别：
吞吐量是数据层的指标，指单位时间内系统成功传输的数据量，以MB、GB等为单位
TPS是网络协议层的指标，指一秒内成功完成的事务数（transaction）

举例：
博尔特1秒跑10米，就计算得一小时能跑：10*3600=36000m，其实博尔特就跑了10s，而36000m这个数的大小，是我们计算出认为如果博尔特跑3600s可以跑36000m。
但是实际上让博尔特真的跑上一个小时，可能就跑了20000m（吞吐量），因为他全程不一定都是保持1秒10米，后面就累了，可能1s也就跑7m，
也就是TPS强调时刻，但是吞吐量强调时间段

监测手段：

1）平均TPS：用聚合报告中Throughput表示

 

 2) 瞬时TPS以及最大TPS：用插件jp@gc-Transactions per Second插件表示

 

 

3）吞吐量

当接口没有报错时可以用聚合报告中Throughput表示；

其次，还可以用插件：图形结果表示

 

 

 

 

apache有个自带的ab工具

ab全称Apache Bench，是Apache自带的性能测试工具。使用这个工具，只须指定同时连接数、请求数以及URL，即可测试网站或网站程序的性能。

通过ab发送请求模拟多个访问者同时对某一URL地址进行访问,可以得到每秒传送字节数、每秒处理请求数、每请求处理时间等统计数据。

命令格式：

ab [options] [http://]hostname[:port]/path

常用参数如下：

-n requests 总请求数
-c concurrency 一次产生的请求数，可以理解为并发数
-t timelimit 测试所进行的最大秒数, 可以当做请求的超时时间
-p postfile 包含了需要POST的数据的文件
-T content-type POST数据所使用的Content-type头信息

更多参数请查看官方文档。

 

例如测试某个GET请求接口：

ab -n 10000 -c 100 -t 10 "http://127.0.0.1:8080/api/v1/posts?size=10"

测试POST请求接口：

ab -n 10000 -c 100 -t 10 -p post.json -T "application/json" "http://127.0.0.1:8080/api/v1/post"

 

Apache JMeter是100%纯JAVA桌面应用程序，被设计为用于测试客户端/服务端结构的软件(例如web应用程序)。它可以用来测试静态和动态资源的性能，例如：静态文件，Java Servlet,CGI Scripts,Java Object,数据库和FTP服务器等等。JMeter可用于模拟大量负载来测试一台服务器，网络或者对象的健壮性或者分析不同负载下的整体性能。

同时，JMeter可以帮助你对你的应用程序进行回归测试。通过你创建的测试脚本和assertions来验证你的程序返回了所期待的值。为了更高的适应性，JMeter允许你使用正则表达式来创建这些assertions.

JMeter的作用对软件做压力测试

1.能够对HTTP和FTP服务器进行压力和性能测试， 也可以对任何数据库进行同样的测试（通过JDBC）。

2.完全的可移植性和100% 纯java。

3.完全 Swing 和轻量组件支持（预编译的JAR使用 javax.swing.*)包。

4.完全多线程，框架允许通过多个线程并发取样和通过单独的线程组对不同的功能同时取样。

5.精心的GUI设计允许快速操作和更精确的计时。

6.缓存和离线分析/回放测试结果。

JMeter的高可扩展性

1.可链接的取样器允许无限制的测试能力。

2.各种负载统计表和可链接的计时器可供选择。

3.数据分析和可视化插件提供了很好的可扩展性以及个性化。

4.具有提供动态输入到测试的功能（包括Javascript）。

5.支持脚本编程的取样器（在1.9.2及以上版本支持BeanShell）。

在设计阶段，JMeter能够充当HTTP PROXY（代理）来记录IE/NETSCAPE的HTTP请求，也可以记录apache等WebServer的log文件来重现HTTP流量。当这些HTTP客户端请求被记录以后，测试运行时可以方便的设置重复次数和并发度（线程数）来产生巨大的流量。JMeter还提供可视化组件以及报表工具把量服务器在不同压力下的性能展现出来。

相比其他HTTP测试工具,JMeter最主要的特点在于扩展性强。JMeter能够自动扫描其lib/ext子目录下.jar文件中的插件，并且将其装载到内存，让用户通过不同的菜单调用。

 

 

官方网站：http://jmeter.apache.org/

解压后， 运行  “bin/jmeter.bat”   

Jmeter 是支持中文的， 启动Jmeter 后， 点击 Options -> Choose Language  来选择语言

 

Don't use GUI mode for load testing !, only for Test creation and Test debugging.

 

不要使用GUI运行压力测试，GUI仅用于压力测试的创建和调试；执行压力测试请不要使用GUI。使用下面的命令来执行测试：

jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
并且修改JMeter批处理文件的环境变量：HEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"

 windows 修改jmeter.bat文件

Jmeter是自带内存空间的，有时候可能会由于内存池占满而卡住无法继续正常运行。

解决方案
打开Jmeter.bat文件，找到其中的这一句，把最后原始默认的256m改成更大的值。
最好是1024的整数倍，如下图：

 

 

jmeter -n -t  xxx.jmx -l  result.jtl -e -o   [Path to web report folder]

 

修改字体

1、调整放大比例（分辨率设置）：jmeter所在目录--->bin--->jmeter.properties,

修改如下（factor=1.8，指放大1.8倍）：
jmeter.hidpi.mode=true
jmeter.hidpi.scale.factor=1.8

语句前的#要去掉，否则不生效。
————————————————

 

改变“消息体数据”（BodyData）代码字体大小：

修改如下：

jsyntaxtextarea.font.size=16

 

https://www.cnblogs.com/yanghr/p/14878864.html

 

 

https://www.cnblogs.com/ixtao/p/13511959.html
原文链接：https://blog.csdn.net/qq_15706227/article/details/122874248

 

打开Jmeter页面：包括测试计划+工作台。

1、Test Plan (测试计划)：用来描述一个性能测试，包含与本次性能测试所有相关的功能。也就说本的性能测试的所有内容是于基于一个计划的。

右键单击“测试计划”弹出菜单：

 

 

注意：

“函数测试模式”复选框，如果被选择，它会使Jmeter记录来自服务器返回的每个取样的数据。如果你在测试监听器中选择一个文件，这个数据将被写入文件。如果你尝试一个较小的测试来保证Jmeter配置正确并且你的服务器正在返回期望的结果，这是很有用的。这样做的后果就是这个文件会快速的增大，并且Jmeter的效率会影响。

如果不记录数据到文件，这个选项就没有不同了。

 

2、Threads （Users）线程 用户

虽然有三个添加线程组的选项，名字不一样， 创建之后，其界面是完全一样的。之前的版本只有一个线程组的名字。现在多一个setUp theread Group 与tearDown Thread Group

1) setup thread group

一种特殊类型的ThreadGroup的，可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行。

setUp Thread Group类似于lr的init.可用于执行预测试操作。

2) teardown thread group.

一种特殊类型的ThreadGroup的，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组。

tearDown Thread Group类似于lr的end.可用于执行测试后动作。

3) thread group(线程组).

这个就是我们通常添加运行的线程。通俗的讲一个线程组,，可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。

 

 

 

 

线程组：

　　名称：就如字面意思，起个有意义的名字就行

　　注释：

　　线程数：这里随便选择

　　Ramp-Up Period：单位是秒，默认时间是1秒。它指定了启动所有线程所花费的时间，比如，当前的设定表示“在5秒内启动5个线程，每个线程的间隔时间为1秒”。如果你需要Jmeter立即启动所有线程，将此设定为0即可

　　循环次数：表示每个线程执行多少次请求。

 

Ramp-Up Period : Jmeter达到指定最大线程数的时间。

循环次数 : 如果是Forever，线程组中的线程将不间断的连续测试系统，当然也可以设置每个线程测试的次数，当完成了规定次数后，该线程将自动退出线程组。

调度器 ： 主要用来指定该测试的一些时间信息，比如从几点到几点运行测试，如果到了指定时间测试没有进行完成，测试也会被停止。

 

 

3、测试片段（Test Fragment）

测试片段元素是控制器上的一个种特殊的线程组，它在测试树上与线程组处于一个层级。它与线程组有所不同，因为它不被执行，除非它是一个模块控制器或者是被控制器所引用时才会被执行。

 

 

 

 

 

 

控制器

JMeter有两种类型的控制器：取样器（sample）和逻辑控制器（Logic Controller），用这些原件来驱动处理一个测试。

4、取样器（Sampler）

取样器（Sampler）是性能测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter 原生支持多种不同的sampler ， 如 HTTP Request Sampler 、 FTP Request Sampler 、TCP Request Sampler 、 JDBC Request Sampler 等，每一种不同类型的 sampler 可以根据设置的参数向服务器发出不同类型的请求。

在Jmeter的所有Sampler中，Java Request Sampler与BeanShell Requst Sampler是两种特殊的可定制的Sampler.
————————————————
原文链接：https://blog.csdn.net/weixin_41853064/article/details/108194275

 

 

 

 

1.Threads：这个组件主要用来控制Jmeter并发时产生线程的数量，在它的下一级菜单下只有一个组件（线程组），可以这么理解每个线程就是一个虚拟的用户。所有的其他类型组件必须是（线程组）节点的子节点。

2.配置单元：和Sample组件一起工作，主要用来配置Sample如何来发起请求访问服务器，这个东西的主要特点是可以把一些Sample的共同配置放在一个元素里面方便管理，配置单元是有作用域的。作用域和树的那个关系一样越是上级节点的作用域越大，越是接近叶子节点的

作用域就越小，可以复写上级作用域的配置。

3.定时器 ： 这个主要是用来调节（线程组），控制线程每次运行测试逻辑（比如说：发出请求）的时间间隔。当然这个下面还有很多类型的定时器，他们主要功能就是调节时间间隔，但个个组件之间的策略有很大不同。

4.前置处理器 和 后置处理器类似一个HOOK，在测试执行之前和执行之后执行一些脚本的逻辑。该组件我还没有具体使用过，但大致功能就是这样，非重点组件。

5.Sample ： 可能上图中没有出现Sample，需要在（ThreadGroup）上添加才可以

Sample表示客户端发送某种格式或者规范的请求到服务端，所以大家看到了各种各样的Sample，其中有两个Http 相关的。一般用HttpClient功能和效率将更强。

6.断言： 意思是指对于Sample完成了请求发送之后，判断一下返回的结果是否满足期望。

7.监听器 : 这个组件不同于平时在Web编程的那种监听器，他是伴随着Jemeter测试的运行而从中抓取运行期间的数据的一个组件，经常使用的是聚合报告组件，从里面可以统计到测试的TPS，响应时间等关键测试数据。

线程组总结

所有的线程组都可以创建多个，并且都是相互独立的，可以勾选执行计划配置中的Run Thread Groups consecutively(i.e.one at time)，来控制是否需要顺序执行线程组。

 

 

Jmeter之Response/JSON Assertion使用

 

我之前用Jmeter做压测的时候，曾经尝试过不用断言的功能，那么一般在什么情况下，Jmeter会报错误呢？我观察了一下，目前我碰到了这2种情况：

(1).返回的http code是：5**和4**

(2).返回的Error Msg是：Connection Timeout Or Reset

返回这两种错误，Summary Report的Error%这栏数值，就会不断的增加。但是，如果接口的返回是这样的信息：

{"errcode":"10600","errmsg":"******服务器异常","success":true}

Jmeter View Result Tree中，这条接口的运行结果是通过的。经过实践，为了得到更准确Error值，我们需要用到断言，这样才能更好了解每个接口的真实压测情况。

一. 首先用到的断言，Response Assertion

我们接口的返回，大概都是这样的格式：

{"errcode":"0","retval":{"code":200,"status":"success","message":"","data":""},"success":true}

使用的方式：

1.Apply to: 接口返回，只有一份报文，不存在多份的情况，所以使用：Main sample only就好了

2.Field to Test：验证返回报文的哪个部分，一般使用Text Response比较靠谱些

3.Pattern Matching Rules：验证返回报文的方式是什么，一般使用Contains，如果用Matches或者Equals，可能会对系统资源有一部分的消耗，特别是返回报文很长、很大的时候

4.Pattern to Test：验证断言的内容，填上对应的期望结果

我个人觉得，Text Response + Contains的方式，应该能满足我80%的断言需求了

官方文档：

https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion​jmeter.apache.org/usermanual/component_reference.html#Response_Assertion

二. 其次用到的断言，JSON Assertion

由于目前很多接口的请求和响应报文都是从XML转到JSON格式，那么相应我们的断言方式，除了大众版的-Response Assertion，理当还有JSON Assertion，那么，我们就来一起说说这个断言的使用。

对于Response Assertion中的响应报文，变成JSON Assertion，如下两图：

通过这样的配置，就完成了从Response Assertion转成JSON Assertion的方式了。

Json格式的报文，最重要的就是访问元素地址

1.Assert JSON Path exists：$.errcode 和 $.success

2.Expected Value：填上期望值，0 和 true

3.Additionally assert value：当需要期望结果等于特定值的时候，选上；我在测试过程中，用上面的例子，勾不勾选，都可以验证成功

我个人觉得，Response Assertion已经能够很好的满足我的要求，同样的验证条件，Response Assertion只需要建立一次，验证多个点

JSON Assertion需要建立多个，每次只能验证一个点

官方文档：

https://jmeter.apache.org/usermanual/component

 

{ "cert_sign":"", "current_beans": [ { "branch_code":"1909291058080031", "buyer_pay_amount":"null", "amont":1 }, { "branch_code":"1909291058080031", "buyer_pay_amount":"null","amont":10 }  ],  "error_code":"0TE110001000",  "error_info":"交易成功",   }

 

获取error_code，$.error_code

获取current_beans中第一条数据branch_code值，$.error_code.current_beans[0].branch_code
获取current_beans中所有条数据branch_code值，$.error_code.current_beans[*].branch_code
获取current_beans前两条数据，$.error_code.current_beans[0,1]
获取current_beans最后一条数据，$.error_code.current_beans[-1：]

用于断言的JSON元素的路径（JSONPath）。
1.Additionally assert value
  是否额外验证根据JSONPath提取的值。
  不勾选，验证JSONPath能否在JSON文档中找到路径；
  勾选，验证根据JSONPath提取值是否预期。
2.Match as regular expression
  预期值是否可以使用正则表达式。
  不勾选，预期值不能使用正则表达式表示；
  勾选，预期值可以使用正则表达式表示。

PYTHON 复制 全屏

预期值
1.Expect null
  若验证提取的值为null，则勾选此项。
  这里有两个地方需要额外注意：
  a.验证null值，还是需要勾选“Additionally assert value”，否则验证的是JSONPath能否找到路径；
  b.预期值不填表示空字符，与null不等价。
2.Invert assertion(will fail if above conditions met)
  若勾选，表示对断言结果取反。

注意：
除了null外，还有一种特殊的值，就是空数组，预期值不能不填，需要设置为：[]
其中[]表示空数组。

json断言示例：https://www.cnblogs.com/qiaoli0726/p/13854385.html

https://zhuanlan.zhihu.com/p/72918260?from=singlemessage

JSON-path语法：

https://www.cnblogs.com/XhyTechnologyShare/p/13906489.html

 

 

jmeter发送JSON请求

第一步先添加 Http header manager

 

 把Content-Type:application/json 添加进去。（复制请求数据中的header信息到粘贴板，点击【add from clipboard】按钮，就自动把header的键值对复制到这里，很方便）

第二步 添加http请求，填写请求协议，ip，端口，请求方式，请求路径，编码格式，post请求的参数填写在消息体数据中

 

 添加察看结果树

 

 

JMeter100个线程竟然只模拟出1个并发

 

 

Thread Properties
Number of Threads (users)
运行的线程数设置，一个线程对应一个模拟用户。

Ramp-up period (seconds)
所有线程在多长时间内开始运行，单位是秒。

比如我们设置线程数为 50，此处设置 10 秒，那么每秒就会启动 50 / 10，5 个线程。如果设置为 0 秒，则 50 个线程会立刻启动。如果设置为 100 秒，就会每隔 100 / 50, 2 秒 启动 1 个线程。

Ramp-up period的大小问题
Ramp-up period的大小问题，对于初学者来说是最容易困扰的。

以下是 5 个线程依次从启动到执行退出的示意图：

 

 

 

红色框起来的部分才是真正 5 个线程并发请求的时间段。

假设我们设置 20 个线程，只运行 1 次迭代，看看不同的启动时间设置会有结果有何不同。

如果启动时间设置为 0，那么测试一开始就会产生 20 个并发请求，服务器万一只能承受 15 个并发，岂不是一上来就 gg 了，还测个什么呀。

如果启动时间设置为 40，那么会每隔 2 秒 启动 1 个线程。万一线程执行不到 1 秒就退出了，第 2 个线程 启动的时候，第 1 个线程已经退出了，不就是只产生了 1 个并发请求么。

**那么设置成多少合适呢？**我也不知道，但是结合我查阅的资料，可以给出一个参考意见。

第一步，把线程组跑 1 次（可以在线程组元件上右键选择 Validate），从聚合报告获取到吞吐量（Throughput）。

第二步，用线程数量除以吞吐量，得出启动时间。

例如，200 个线程，跑一次获取到吞吐量为 4/sec，启动时间为 200 / 4 = 50。这样设置以后，第 2 个线程启动后，刚好第 1 个线程执行完开始新的迭代，从而形成梯度递增的并发请求。

Loop Count
迭代次数。可以填写数字指定迭代次数。也可以勾选 Infinite，表示无限迭代，一直运行到测试停止或异常崩溃。

Same user on each iteration
在 JMeter 中，user 就是线程，此选项的意思是说每个迭代都用相同的线程。

这个得从老版本讲起，在以前 3.x 和 4.x 版本的 JMeter 中，是没有这个选项的。创建好 1 个线程后，每次迭代都是用这个线程，直到测试结束。它的影响就是，比如登录，加了 HTTP Cookie 管理器以后，单个线程多次迭代（注意不是多个线程哦）登录用的都是相同的 Cookie。

5.x 版本加入了这个选项，可以控制每次迭代是否创建新的线程。同时在 HTTP Cookie 管理器也增加了一个选项，控制是否清除旧 Cookie：

 

**默认这个 Same user on each iteration 的选项是勾选的。**因为销毁和创建线程本身就会占用资源，可能会影响性能测试结果。

Delay Thread creation until needed
跟 JVM 创建线程时机有关，实际运用勾不勾选都不影响测试结果，保持默认就好。
————————————————
原文链接：https://blog.csdn.net/weixin_45741835/article/details/109595706

 

 

参考:

https://blog.csdn.net/w565911788/article/details/7629787

https://blog.csdn.net/weixin_41853064/article/details/108194275

https://www.cnblogs.com/TankXiao/p/4045439.html#howtoLearn

https://zhuanlan.zhihu.com/p/192742927

 

简单压力测试：https://www.cnblogs.com/TankXiao/p/4059378.html

 https://www.cnblogs.com/wangjunjiehome/p/15682921.html