第二篇：linux系统Jmeter性能测试笔记

jmeter性能

jmeter P函数应用

${__P__(thread,200)}

${__P__(step，20)}

${__P__(steptime，30)}

${__P__(duration，30)}

${__P__(duration，300)}

jmeter  -n -t  待执行的性能脚本jmx  -l  结果文件（名字自己取）jtl  -j  执行的loglog -e -o 路径/测试报告名  -Jthread=20  -Jstep=20 （参数不加则默认）

$ nvidia-smi 查看显存使用情况命令

$ watch -n 10 nvidia-smi 周期性地查看GPU使用情况 10 表示每10秒刷新一次GPU状态

vmstat interval count

      间隔时间  需要输出多少次结果

vmstat 2 10

      每隔两秒输出10次结果

top  ps（使用时间C列 time为进程持续时间）

CPU 占用率 = （进程 cpu时间/ 进程持续时间）

ps -ef -elf

ps -au -aux

%cpu %men

CPU 中央处理器 GPU图形处理器

GPU 是图形处理器，在测试手机/游戏性能会用到（模型性能也会用到），如果是测试web后台性能，应该不用

查看和杀死Jmeter进程

jps | grep ApacheJMeter | awk '{print $1}'

jps | grep ApacheJMeter | awk '{print $1}'|xargs kill -9

后台执行

nohup jmeter -n -t 执行的脚步jmx -l 结果文档jtl &  后台执行，即使关闭窗口后也执行

jmeter -n -t 执行的脚步jmx -l 结果文档jtl & 后台执行，关闭窗口后不执行

linux下测试性能 不含事务控制器的情况下打印的信息：

其中主要有两种信息 summary + 和 summary = ，其它项都是类似的

summary +4386 in 00:00:30 ：在30秒内增加了4386个请求，其中时间间隔由配置文件中的interval统计频率的值决定

summary = 27455 in 00:03:12 ：在3分12秒内产生的总请求数是27455个，其中的时间段是从脚本运行开始计算到当前时间为止，一般在脚本运行过程中主要关注"summary="信息即可

1462/s ：系统每秒处理的请求数，相当于TPS

Avg : 684 ：平均响应时间

Min:201 ：最小响应时间

Max:1499 ：最大应时间

Err : 0 (000%) ：错误数/率

Active :100 活动的线程数

当没有遇到性能瓶颈的时候：

F=VU R /T

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

1、右键单击测试计划，选择添加-〉线程组

在线程组里设置负载信息，即线程属性。我向测试计划中增加相关负载设置是Jmeter需要模拟十个请求者，每个请求者在测试过程中并发请求，并且连续请求10次。

线程数： 10

Ramp-up period（inseconds）： 0

循环次数： 10

说明：线程数代表发送请求的用户数目，Ramp-up period（inseconds）代表每个请求发生的总时间间隔，单位是秒。如果我的请求数目是5，而这个参数是10，那么每个请求之间的间隔就是10／5，也就是2秒。如果设置为0就代表并发请求。Loop Count代表请求发生的重复次数，如果选择后面的forever（默认），那么 请求将一直继续，如果不选择forever，而在输入框中输入数字，那么请求将重复 指定的次数，如果输入0，那么请求将执行一次。

固定吞吐量定时器（Constant Throughput Timer）可以让JMeter以指定数字的吞吐量（即指定TPS，只是这里要求指定每分钟的执行数，而不是每秒）执行。吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组，并且计算吞吐量的依据可以是最近一次线程的执行时延。

如果想自己定义throughput的变化也是可以的，需要使用BeanShell定时器（BeanShell Timer）

这个定时器，平时用不上。但实际上，它是最强大的，因为可以自己编程实现想要干的任何事。有复杂需求时，就要靠它了。例如，希望在每个线程执行完等待一下，或者希望在某个变量达到指定值的时候等待一下。

测试场景 ：回归push推送任务是否正常

*** 作流程 ：后台创建push推送任务，待任务推送成功后，检验推送是否正确（备注：push推送后的跳转类型有很多种，如跳转分为原生页面和H5页面，原生页面又分为知识、语音等等）

测试痛点 ：每次回归需要创建不同跳转类型（粗略统计大概有五六十种）的push任务，很耗时，如何提高效率？

jmeter脚本实现 ：1、批量创建各种不同跳转类型的push任务；2、检查日志文件是否发送成功

涉及接口：两个接口-创建push任务接口（/message-admin-web/rest/pushTask/save）和检查日志接口（/message-admin-web/rest/pushMessageLog/list）

1、首先需要解决登录后台的问题，最简单的方法就是：第一步、jmeter创建>

问题：有一个页面，需要测试一下最大支持多少用户并发？

此时需计算的是最大用户并发数，强调的是同时 *** 作，也可以理解为同时发起请求；

针对这个问题，我们可以通过rps定时器或阶梯加压线程组测试每秒最大的请求数；

首先需要导入jmeter-plugins插件 ，然后去初始化需要用到的插件

在平衡状态下，并发数=RPS响应时间

a）使用jp@gc - Throughput Shaping Timer （吞吐量成形计时器，调节rps的定时器）；

设置线程组中线程数为50，ramp-up时间为1s，永远循环；

同时在请求下面加Throughput Shaping Timer定时间，rps由1增加到400/s；

测试最终运行时间取 线程组运行时间 与 定时器时间的最小值；

设置后我们需要添加几个性能测试中常用的监听器：

添加监听器Hits per Second（每秒请求数）

观察HPS走势，HPS在140的时候持续了十几秒，随后HPS稳定在100

 添加监听器 Transaction per second

TPS在48/s稳定了十几秒，然后稳定在30/s

  添加监听器 jp@gc - Response Times Over Time

平均响应时间在3s以内

 在比较稳定的情况下，最大rps=140/s,平均响应时间=16s，则最大并发=14016=224，也就是224个线程同时启动可满足1s内140/s HPS压力值

b）使用阶梯加压线程组

功能如下：

This group will start 100 threads ：设置线程组启动的线程总数为400个；

First,wait for N seconds ：启动第一个线程之前，需要等待N秒；

Then start N threads ：设置最开始时启动N个线程；

Next,add 100 threads every 2 seconds,using ramp-up 10 seconds ：每隔2秒，在10秒内启动100个线程；

Then hold load for 40 seconds ：启动的线程总数达到最大值之后，再持续运行40秒；

Finally,stop 100 threads every 0 seconds ：同时停止100个线程；

设置阶梯线程组各配置项后，再添加各个监听器后观察，发现得出的tps，rps，平均响应时间与添加rps监听器测试出的结果基本一致

下面可以来验证一下，线程组的线程数设置为224，其它值可随意，（如，设置定时60s，循环次数设置为100，因为并发数=rps响应时间 是在平衡状态下得出的结论，所以运行时间不能太短）

添加监听器Hits per Second，Transactions per Second，Response Times Over Time 查看这些指标是否和上面得出的结果一致（预期应该是满足的）

我们要测试的网站地址是什么？链接是什么？所以现在我们就来设置这些信息。右键点击我们刚创建的线程组，在d出的菜单中，选择添加->Sampler->>

以上就是关于第二篇：linux系统Jmeter性能测试笔记全部的内容，包括:第二篇：linux系统Jmeter性能测试笔记、jmeter聚合报告中的时间是以什么为单位、jmeter定时器能不能设置时间点等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！