性能测试_Jmeter学习

　今天来学习下jmeter这个性能测试工具，虽然说性能测试最主要的是整个性能的思路，但是也少不了工具的帮忙，从以前主流的LR到jmeter的兴起，不过对于性能测试来说，个人感觉jmeter比较适合接口性能测试（因为工具比较轻盈，而且主要是模拟用户负载，当然我也不否认可以做多业务的性能），既然说到这里，那么来简单说下jmeter的优缺点，当然这个也主要是跟LR进行的对比，这里简单说几个：

　　　jmeter优点：

• 开源，不收钱
• 工具小但能干的活却基本上接近LR
• 扩展性强，而且懂java的人比C多

　　缺点：

• 缺少一个成型的体系，初学者学性能没有整体概念，且界面也没那么爽，刚学的人是懵逼的，跑起性能来啥情况都不知道
• 最大的吐槽点应该就是对于线程的管理，LR是有专门的进程对多线程进行管理，而jmeter则是无脑开（无脑开线程会导致cs指标升高，cs代表进程与线程的交互次数，上篇讲过），把自己搞死了都不知道。。。
• 录制也没LR那么爽，LR能对很多资源自己丢一个请求里面，jmeter不行，录制都是一堆鬼玩意，所以说这个东西做接口压测比较好

行了，不多说了，我们来接着学习jmeter的使用吧，在学习用之前，我们先看下jmeter有哪些目录以及是干啥用的。这里玩的是新版本jmeter4.0。

jmeter4.0的目录如下：

• backups（这个之前版本是没有的，4.0新增的，备份脚本的目录，当然还是自己记得保存最好，万一它没保存那就尴尬了）
• bin（可执行文件目录）

  1. examples（目录中有CSV样例）

  2. jmeter.bat（windows的启动文件）

  3. jmeter.log（jmeter运行日志文件）

  4. jmeter.sh（linux的启动文件）

  5. jmeter.properties（系统配置文件）

  6. jmeter-server.bat（windows分布式测试要用到的服务器配置）

     扫描二维码关注公众号，回复： 2539272 查看本文章

  7. jmeters-server（ linux分布式测试要用的服务器配置）

• docs（文档目录，api文档）
• extras（扩展插件目录，ant依赖，里面还有监控的GrafanaJMeterTemplate.json，就是上次监控提到的jmeter监控模板）
• lib：所用到的插件目录，里面全是jar包，JMeter 会自动在 JMETER_HOME/lib（这个目录下是依赖的外部jar包） 和 ext 目录（核心jar包）下寻找需要的类
• Printable_docs（用户使用手册，帮助文档，英文好的看这个目录的文档就可以进行修炼了）
• Licenses（jmeter证书目录）

现在就让我们来学习下jmeter的正式使用吧，用jmeter进行录制有两种方式，一个是badboy一个是jmeter代理录制，当然除了录制你还可以手写，这个也是比较常用的。下面就来简单说下代理录制：

由于需要jmeter测试，所以我在cantos7.2上已经安装了lamp和phpwind8.5，有人说这个环境安装有点麻烦，我这里稍微提一下吧，安装总共分为两步，第一个是先装lamp，我是安装这篇博客来的，https://blog.csdn.net/u012980068/article/details/70228424，装完之后就去下载phpwind8.5 utf-8的版本，然后把upload改成phpwind丢到/var/www/html下，注意一下在做这些操作前要关闭防火墙和selinux，丢完之后最好将phpwind整个都赋予777的权限，然后去到界面通过http://ip/phpwind访问安装即可。

打开jmeter之后，新建线程组和HTTP代理服务器，然后选择目标控制器为“Test Plan > 线程组”，由于jmeter录制请求的时候会很多js、css等资源，因此我们可以通过包含模式和排除模式过滤一些不必要的请求，一般在做项目性能的时候，建议先录制，我们可以参考着录制然后抓包写请求，除非你牛逼，对业务前后台非常熟，否则还是录制参考下，以免遗漏请求。

这里我们来看下jmeter常用的一些组件，这些组件等下我登录发帖整个流程会用到：

1. 逻辑控制器
   • 事务控制器（一般把几个操作放在一个事务，便于管理）
   • 仅一次控制器（一般用于登录）
2. Sample
   • http请求（主要是用于http请求）
   • java请求（主要用于自己条使用）
   • Debug sample（也是debug调试用的）
3. 前置处理器->这里面好像就一个用户参数用得比较多
4. 后置处理器->这里面是正则表达式用的比较多，主要用于关联
5. 断言->我一般都用响应断言，这里主要是做检查点的
6. 定时器->固定定时器比较多，用于模拟用户思考时间等，也可以不用，看业务需求
7. 配置元件
   • CSV 数据文件设置（主要用户参数化）
   • HTTP Cookie 管理器（用于cookie管理，一般我们都需要）
   • HTTP信息头管理器（有些请求需要特殊的请求头，此时可以进行添加，一般我们录制后的每个请求都会带一个信息头管理器）
   • HTTP请求默认值（一般放在最前面，这样所有请求都只需要填写路径即可，而且ip变化之后只需要改这里就行了）
8. 监听器
   • 查看结果树（查看每次请求的具体内容）
   • 聚合报告（所有请求的统计过程）

下面我以登录发帖为例，给大家讲解下jmeter部分常用组件的用法，我们首先来指定一个场景，场景如下：

总共10个用户请求，每5秒2个用户登陆然后开始发帖，每个用户登陆一次然后每隔一秒发一次帖子，十个人持续发帖60秒，然后按照5秒两个用户停止发帖。（场景可以自己随便定义，举个例子而已），场景设置如下图，是不是和LR很像呢？这个需要先下载jmeter插件才会有的，可以百度搜索“Jmeter plugin”然后下载解压将jar包放在lib->ext下。

　　接下来大致讲解下用到的元件，从上往下依次说下，这里不会详细说明每个组件的意思，不懂得可以百度，有太多说明了。我主要是讲解一下思路，

1. 首先我们看到在最前面有个cookie管理器，这个是需要的，因为没有这个的话那我们登录之后发帖的事就干不成了，这里注意一点就是有个“每次反复清理cookie”的选项，如果选了就会每次清理cookie,这里我们是仅登录一次所以不勾选；
2. HTTP请求默认值，我们对论坛进行测试，那么就可以将每个请求默认访问服务器的地址先写在这个请求默认值里面，第一是以后请求可以少些点东西，第二如果ip发送了变化，那么我们只需要修改这里就行了。
3. 仅一次控制器，我这里将登陆的请求都放到了仅一次控制器下面，这里要注意下，那个csv的参数文件也必须放在这里，如果放在外面的话那么发帖也会自己读参数，所以发帖的参数跟着登陆的就行了。
4. CSV 数据文件设置，这里我们参数化了用户名和密码（之前已经通过参数化注册了两百个用户，需要注意下，如果是注册的话倒数二三的选项要与下图相反）
5. 响应断言，这里主要登陆登陆和发帖做了两处断言，你可以先成功登录和发帖一次看下成功和失败不同的响应是啥，然后断言即可。
6. 正则表达式提取器，这里我们在发帖的参数发现有个参数verify是一直变的，因此我们将其关联，关联的参数要在发帖前的页面去寻找，找到后用正则提取出来即可，可能找到的会不只一个，所以我们选择了第一个。
7. 事务控制器，这里我将点击跳转至发帖页面和提交发帖还有跳转读贴为一个事务，因为这跟我们用户操作是一样的，我们发帖都是等跳转至发完贴的页面用户才能感知到发帖成功，因此算作一个事务，可以看下事务控制器有两个勾选项，可以看下意思，默认是没勾选的。

• Generate parent sample：(选中这个参数结果就只会展示整个事务，不会显示每个请求，不勾选则显示每个请求和事务)
• Include duration of timer and pre-post processors in generated sample：选中这一项会统计定时器(timer)的时间，否则只统计采样器(sample)的时间

8.固定定时器，这里只是模拟一下用户发帖前需要填写帖子内容再发，这里设置为了1秒，实际上应该不止一秒的，这里只是做个测试而已。不过这个固定定时器的时间虽然不会计算在请求内，但是会计入到事务内，因此我们在看响应时间的时候可以减去这个时间，也可以取消事务的勾选，看下单个请求的时间。

9.最后添加一个查看结果树和聚合报告看下情况，还有Backend Listener，这样我们的数据就会写入到influxdb里面，我们可以结合之前我们写的jmeter模板还要linux监控一起看下测试情况和资源使用情况。

我们跑起来看一下整天情况，在跑之前我先看下帖子的数量：3810个帖子

我们开跑，可以从这里看到一分多钟的时间，总共发出去了736个请求，所有请求都成功了，所以帖子数也变成了4546个；

下图可以看到TPS为9.2（持续60时候的峰值TPS），对应响应时间为50ms，整个事务的时间是100+ms，看完这个后，我们来接着看下监控。

 监控如下，可以看到在17:40：30的时候，TPS是最高的，cpu使用率为也是占用最多，可以看到队列数为3，上下文交互是2K，可以看到在该压力下，系统的各个指标还未达到任何瓶颈，这里主要是给大家串一下整个思路，之后会根据实战具体分析下性能，感兴趣的也可以并发多用户或者把固定时间去掉提高TPS，看下性能如何？

在这里我又重新执行了下面的场景，而且去掉了固定时间，所以整个的压力是非常大的，我们来看下结果：

jmeter各个请求及事务的情况如下，可以看到最大的发帖时间已经有1+秒了，TPS最大为25左右也上不去了，接着我们再看下服务器资源监控：

论坛服务器的服务器配置是2C2G的，所以看到队列有50+个，我们可以知道，cpu肯定是扛不住这么大的压力了。嘻嘻，简单分析到这里吧！以后再来更详细的分析咯。

 给个 喜 欢，好 不 好！