性能测试七：Jmeter测试脚本（一） 脚本录制、IP欺诈、乱码、组件顺序、启动线程数

一、Jmeter录制手机APP

---

 代理录制的原理：

• Jmeter录制是针对网络通讯协议层面的，它只关心客户端与服务器端的通讯包。

• Jmeter录制脚本采用proxy的方式

• 客户端请求的数据会先发到proxy服务器(录制器)，录制器将数据转发给服务器端。

• 服务器端的响应数据先发给录制器，然后由录制器响应给客户端。

 

录制手机APP步骤：

步骤1：创建线程组，并在线程组下添加HTTP请求默认值

• 若服务器或IP、端口、路径没有输入值，那么代理录制则可以录制任何地址的操作（一般默认不输入值）
• 若服务器或IP、端口、路径有输入值，那么代理录制则只能录制输入IP地址的操作

步骤2：在线程组下添加录制控制器（逻辑控制器下），方便对录制的操作进行有效控制和管理。

步骤3：在线程组下添加HTTP代理服务器（非测试单元下）

步骤4：配置代理连接的端口号和录制操作存放位置（如：Test Plan > 线程组 > 录制控制器）

步骤5：配置手机端（注意：手机与电脑必须在同一个网络环境才能进行录制）

 步骤6：配置手机代理

 步骤7：配置完成后，用手机进行操作，查看Jmeter录制情况

步骤8：录制完成后

• 只保留与性能点相关的内容

• 异步处理的保留多个请求

 

二、Jmeter实现IP欺诈

---

为什么会用到IP欺诈

1）当某个IP的访问过于频繁，或者访问量过大是，服务器会拒绝访问请求，这时候通过IP欺骗可以增加访问频率和访问量，以达到压力测试的效果

2）某些服务器配置了负载均衡，使用同一个IP不能测出系统的实际性能

3）很多网站会限制IP登录，一个IP只能登录一个用户，为了更加真实的模拟真实情况，这时候需要使用IP欺骗来达到不同IP登录多个用户的效果

 

实现IP欺诈步骤

步骤1：查找发压机局域网内不要有IP冲突，可以事先ping一下找没有使用的IP，但子网掩码必须一致，ping后提示：“无法访问主机”该IP可留用

步骤2：手工设置多IP绑定同一网卡：在网络共享中心 -- 本地连接 -- Internet协议版本4 -- 属性 -- 高级 -- 添加IP设置，如下图：

步骤3：创建一个.csv的文件用来存储IP地址，在jmeter测试计划中添加配置元件读取IP地址 IP = ip.txt

步骤4：Jmeter设置HTTP请求，http请求设置Implementation = " HttpClient4 "，IP/Hostname = ${IP}

 

 

三、Jmeter中的前置处理器

---

• JSR233编写Groovy脚本

• JSR233编写BeanShell脚本

• BeanShell编写BeanShell脚本

结论：

• JSR233组件下的BeanShell性能非常差。
• 同一个场景中，如果有的脚本使用了JSR233组件下的BeanShell语言，那会严重影响当前场景下的所有BeanShell组件模块的性能；同时也会稍微影响JSR233组件下的Groovy语言的性能，导致其TPS略有下降。
• BeanShell组件下的BeanShell语言性能比JSR233组件下的Groovy语言性能稍差，实测TPS基本一致。
• 在编写JMeter脚本的时候，千万不要使用JSR233组件下的BeanShell语言，如果要使用BeanShell语言一定要用BeanShell组件下的。

 

四、Jmeter脚本中的乱码问题

---

 1.乱码为古文+日韩杂文 　　　 产生原因：以GBK方式读取UTF-8编码的中文

2.��大部分为小方块 　　　　产生原因：以UTF-8的方式读取GBK编码的中文

3.é˜¿è¾¾å 　　　　　　　　产生原因：以ISO8859-1方式读取UTF-8编码的中文

4.最后字符变？？ 　　　　　　产生原因：以GBK方式读取UTF-8编码的中文，然后又用UTF-8的格式再次读取

5.锟金拷 　　　　　　　　　　产生原因：以UTF-8的方式读取GBK编码的中文，然后又用GBK的格式再次读取

 

解决乱码问题：

步骤1：使用抓包工具对JMeter发送的请求和服务器端返回的响应进行分析，检查JMeter的编码设置是否与服务器端相同。在JMeter的bin目录下找到jmeter.properties文件，在文件中搜索“file.encoding”参数，确认是否与服务器端编码一致。可以通过设置该参数进行调整。

步骤2：检查请求头和响应头：在JMeter中，可以在HTTP请求中添加请求头和响应头，检查是否有编码相关的参数设置。如请求头中Content-Type和Accept-Encoding参数，响应头中Content-Type和Content-Encoding参数等。

步骤3：调整字符集编码：在JMeter的HTTP请求中，可以设置字符集编码，如UTF-8等，保证请求和响应中的数据使用相同的编码方式。

步骤4：如果以上方法均未解决问题，需要检查服务器端的编码设置是否正确，如服务器操作系统、数据库字符集等。

 

五、聚合报告中的 接收Received KB/sec

---

Received KB/sec ：指的是我接受数据的能力是1923.08KB/s ,这里就牵扯到了带宽问题，带宽限制流量，假如被压测的服务带宽为：20mb（兆） 那么服务的下载速度为 20*1024/8=2560kb/m,。

Received KB/sec有两种限制，一个是客户端的上传速度，和服务端的下载速度，如果客户端的上传速度为1.7m/s,那么这块最大只能显示1.7m/s ，如果客户端上传速度为1.9m/s，服务的下载速度为1.5m/s，那么这里的最大只能显示1.5m/s，谁小取谁。

 

六、Jmeter组件执行顺序

---

 

01 > 执行线程组

02 > 执行简单控制器

03 > 执行配置元件HTTP Cookie管理器

04 > 执行前置处理器用户参数

05 > 执行同步定时器，类似于LoadRunner中的集合点

06 > 执行取样器业务请求1

07 > 执行后置处理器正则表达式提取器

08 > 执行断言响应断言

09 > 执行配置元器件HTTP Cookie管理器

10 > 执行前置处理器用户参数

11 > 执行同步定时器，类似于LoadRunner中的集合点

12 > 执行取样器业务请求2

13 > 执行后置处理器正则表达式提取器

14 > 执行断言响应断言

15 > 执行业务请求3，HTTP Cookie管理器将不覆盖此请求

16 > 执行过程中在查看接过书中可以看到结果，红色字体代表失败。此元件是在取样器执行后开始工作的。

 

七、Jmeter启动线程数

---

假如压力机为4c8g，可用内存为3.5g左右，启动一个线程需要1M（一个http请求），1000个线程大概需要1G

假如JVM设置Xms512m，Xmx1024m，1000VU，会导致Out of Memory

另外在运行过程中，Jmeter又使用了Respoonse Time、TPS、Thread等等的计数器也会占用额外内存

 

建议：单台压力机，线程数推荐500个左右

Xms，JVM启动占用内存大小，初始堆大小 X memory startup
Xmx，JVM运行最大可占内存，最大堆大小 X memory maximun
Xss，每个线程堆栈大小 X ThreadStackSize

 

关于Jmeter线程数的一些问题及答案

问题：linux操作系统1个进程可以运行多少线程数？

回答:

每个进程都有各自的私有用户空间（0-3G），这个空间对系统中的其他进程是不可见的。

每个进程运行的时候，都会拿到4G的虚拟内存，在32位Linux下，其中3G是交给用户的，1G是交给内核的

 

问题：是不是说一个jmeter进程启动2048个线程？

回答：

只是理论上，但是内存当然不可能完全拿来作线程的栈，所以实际数目要比这个值要小，你也可以通过连接时修改默认栈大小，将其改的比较小，这样就可以多开一些线程。 如将默认栈的大小改成512K，这样理论上最多就可以开4096个线程。

 

问题：jmeter平均响应时间和TPS的计算方法是什么呢？

回答：

平均响应时间 = 所有sample样本响应时间和/样本个数

例如：

20s/100个 = 0.2s

TPS=(sample样本数)/（结束时间-开始时间）

例如：100个/2s = 50tps/s

 

问题：如何控制jmeter发出的并发数？

回答：

线程数为100的时候，run_up时间为1s，如果平均响应时间小于1s，则可以加大线程数，不超过2048的线程理论值。

因为tps的计算方法是按照秒计算，实际上平均响应时间小于3s都在可以接收范围之内。

一味的追求tps的数据，对于服务器有要求，对压力机也有要求，且对网络带宽也有要求，如果想要在1M带宽下达到过高的tps无疑是痴人说梦。

 

问题：那多少带宽可以支持多少线程数？

回答：

1Mbps宽带理论上可以传输128KB的数据，具体计算方式为 1*1024 = 1024KB，1Mbps的bit换算为byte 为8:1 ，则1024/8 = 128KB

1KB等于1024字节，一个汉字占2个字节

如果一个http请求，请求数据为50个汉字，则128KB*1024/(50*2)（一个汉字2个字节）= 1310个请求/s

如果每秒请求10次，则是1310/10 = 131个请求/s

注意：

这也是理论上能达到的处理请求数量，根据请求的图片和数据量的大小，数据是有波动的。

用户可能下载图片，每秒下载一次图片大小为10kb，计算公式为 128/10 =12.8 人

 

问题：那我们还需要关注测试压力机的cpu等信息吗？

回答：

这是肯定的，当cpu被其他的程序所占用的时候，进程中的线程无法获取足够的cpu内存等支持，也是会阻塞排队，影响测试结果的，最好cpu的占用率维持到80%以下，确保压力机本身请求发起是有效的且无丢失的。还要确认程序是否发起了足够的线程。

 

问题：为什么我没有启动太多线程，但是jmeter报错堆栈溢出呢？

回答：

可以修改jmeter 内存 参数设置，编辑jmeter.bat

set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=1024m 保存后(1024的倍数)，

打开jconsole查看是否修改成功，修改之前也可以查看