jmeter功能介绍(三)

连载jmeter功能介绍二
csv data set config



dummy
用于调试使用，可以自定义返回内容。




Console Status Logger
将执行信息过程，命令行打印出来

命令行执行
D:\Program Files\apache-jmeter-5.0\apache-jmeter-5.0\bin
$ jmeter.bat -n -t D:\study\jmeter\cvs.jmx
Creating summariser
Created the tree successfully using D:\study\jmeter\cvs.jmx
Starting the test @ Sun May 26 10:17:24 CST 2019 (1558837044118)
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
#0 Threads: 1/3 Samples: 1 Latency: 79 Resp.Time: 185 Errors: 0
summary = 9 in 00:00:01 = 6.2/s Avg: 218 Min: 129 Max: 425 Err: 0 (0.00%)
Tidying up … @ Sun May 26 10:17:25 CST 2019 (1558837045960)
… end of run

beanshell
语法与java类似

示例1

//导入jar包
import org.apache.commons.codec.digest.DigestUtils;

public static test(){
//定义需要加密的参数并将其进行拼接
String parm="123456153452415";
//调用MD5hex方法生成最终的加密串
String mxd=DigestUtils.md5Hex(parm);
//将生成的加密串赋值给变量mxd，这样可以便于后续的使用
vars.put("mxd",mxd);

vars.put("test","gloryroad");

return "success";
}

test();

用处：可以生成参数化数据
示例2

package cn.gloryroad;

public class Myclass
{
    public int add(int a, int b)
    {
        return a + b;
    }    
}

把java外部的文件导入进来使用

在做性能测试的时候常常反思的几个问题：

• 性能测试的全流程是什么？ 什么项目需要做性能 怎么算是性能测试完成的标准 量化的指标是什么？如何定义？ 性能测试的环境模型如何建立
• 性能的监控如何实现? 报告怎么写？
• 压力测试只是性能测试中的一种。
• 在不同的压力下，系统的性能表现。
• 压力测试，以系统出错为目标。负载只是关注指标变化。
• 压力测试强调短时间内，稳定性测试长时间。发现资源泄露，容量问题。死锁，连接数施放。

任何的上线一定要测试性能。无明显的问题。系统出错，系统会有错误日志。-- 如：在线监控，跑所有与数据库交互的功能。

干系人：
自己（QA），系统架构师（高级开发），运维，DBA
系统级优化（参数）提升整个项目性能指标提升10%，DBA。
架构不合理，数据库的问题。索引建的不好，慢查询不好，连接数问题。
定性能指标标准：下载网页时间场，加CDN(Content Delivery Network)
后端的性能：接口，服务

1.收集信息
各种需求，系统架构设计，数据库数据，项目时间安排
是否有明确目标，没有指标问期望的运营指标（注册用户，日活，月活…）。参考这些指标进行设定性能指标。
指标的指定是最复杂的事情。
了解子系统，了解通讯机制，关注信息传输。每个子系统是否满足运营指标。每个子系统如何工作，接口，每个接口的指标是什么？将高层次的运营指标拆解到子系统中是否满足。
关注系统有什么好处和不好的
好的地方是否满足，不好的地方，存在何种风险。如何做评估。

数据库：主从同步。不能将所有数据放到一个数据库里。表中的数据不能太多。分表无效的时候，要分库。解决什么问题？提升访问速度。主库写入使用。从库做读使用。
业务读的使用比写多。写完才可以读，读的数据量很大，会让写的速度变慢。这件事儿需要与用户进行交互。立刻看到成功。写不能被读堵塞，所以要分离。数据库没有做分布式同步，需要建议。
分库分表。
服务器一台down的话，建议双master。
风险：数据库，缓存（如果down机，如何恢复，从哪里恢复，恢复多久，恢复多少数据），缓存不能工作，系统能否给用户使用。

性能测试原则：
模拟所有可能发生的极端情况，验证系统（包括各种子系统）是否满足用户或者公司的使用和运营要求

信息收集
了解技术实现，测试数据，相关测试数据的关系，为后期测试做准备
功能可用,就可以开展性能测试.(压测)

性能优化方式
架构优化(压力)

在线监控.
环境建模,同比例缩小.每个节点要模拟到.

应用-缓存-数据库-反向代理.
每个分布式原理需要验证.

拐点:平滑上升之后,持平,再下降.
因为CPU要给每个进程分配资源,处理排队,上下文切换.导致TPS反而越来越小.
拐点,代表系统最佳处理能力.

压力测试的最佳点代表大量出错的时候,该点不一定是TPS.

运行时间最佳:7*24,一般周末两天.
内存一直持续增加,不减少.

容器:类似list,一直往容器里放东西,内存会爆.
执行一段时间之后,null到,清空引用.

并发数与TPS无直接关系,在未达到最大值之前,并发越大TPS越大.
上线之后,监控并发量.侧面监控,1s出现了多少请求.
并发数,上线之后监控不到.只能看到参考数.并发数开大一点.
监控连接数: linux命令 netstat -anp|gerp 端口
[root@iZ2zejbxp2btn9jh8knipuZ ~]# netstat -anp|grep 3306|grep ESTABLISHE|wc -l
1

nomo:监控linux系统

c:查看CPU

m:查看内存

d:查看磁盘

n:网络

好处:可以生成监控结果.
性能指标:
TPS,平均响应时间.附加参考值,CPU占用不能超过70%.内存要有富裕30~40%.
io:富裕30~40%
数据量:数据库加载值.

测试策略:
1.先单个接口还是混合
2.先测试UI还是先测试接口

系统支持水平扩展?
当机器出现问题,是否可以通过增加机器提升系统处理能力.好处:系统是否支持扩容.提升系统可用性.
考虑系统

影响结果因素: 测试数据差异,测试环境差异
虽然环境不一致,程序和系统明显问题还是可以发现,发现大多数问题,架构问题,分布式计算,缓存机制,连接数等.

测试环境
最佳环境:使用线上环境进行压测
全链路压测:在线上环境进行压测,需要隔离动作.测试数据不能进入生产环境,试别压测数据和生产环境数据,分离数据.同时分离数据库.系统要做改造.改造失败,测试数据和上线数据分开.
业务系统尽量不要秒杀.分布式节点尽量两台.软件版本也相同.

网络环境:局域网进行压测,不要使用公网.跨网络会产生延迟,加压的压力会出现带宽等问题.

差异部分要体现在测试报告中.

指标确认:
多长时间架构保持不变.
问运营:一年的指标多少?多少货物?注册用户数?一起开会定一个.
造数据:
有页面,用loadrunner压.不需要了解表结构
python写,自动化脚本
第三方工具datafactory
存储过程:了解数据表结构.调用数据库底层的代码.

数据可以多加一些.多增加20~50%.
数据库也有缓存,提供服务的东西有缓存.保持跟现象保持一致

不同cache压测不同结果.
缓存:最开始空,访问一个数据,先去缓存层看是否有,如果没有去数据库拿.
看被测系统缓存层是否满不满.

n+1 : n是多线程并发的东西,1单独找一台机器,开一台机器访问被测系统.看访问是否一致.

创建测试场景:
10个接口如何制定场景
同时压测,但是频率不同,压测并发量不同
单个接口测试,再组合测试.
依次调用30ms以下, 30~100ms中等,100ms以上比较差.不包含网络传输.看日志调用返回的时间.
批量调用接口,1s以内可以接受,返回大量数据.
数据平台层:调接口,提供数据.数据存储在一个地方,不同应用调用相同的接口,提供数据.

loadrunner: 通过代理抓包的方式,转换成loadrunner脚本.
测试地方:
涉及到数据库的地方,都要做压测.一般读库很慢,慢查询.
用户核心使用的功能,io操作比较多(写很多文件).
系统产生密集计算的方法,耗CPU.(比如,做用户登录验证.用户传入的数据会进行加密解密,耗cpu)
压核心的,经常被调用的.

性能分两种:
一种接口:接口层容易产生瓶颈.一个接口给应用提供服务.应用层不涉及数据库存储.
一种页面:产生瓶颈的概率比较小

数据库效率比较低.
先单个接口测,是否有明显问题.再测试混合组合.查看整体接口压测.可以按照权重分配.

性能测试成功:
1.达到明确的测试指标
2.压死了算.出现拐点.
3.性能指标比之前的好

系统调优
软件参数
慢查询
缓存命中率太低,未达到30%,说明效率太低.

验证通过后,可以看水平扩展的能力.能应急就行,增加机器不一定会无限制的增加系统性能.
水平扩展之后,可能会产生新的瓶颈

没有可以比较的测试结果,分析运营指标,找到并发三个月内历史峰值的四倍.

好的接口应该是无压力与负载测试时,性能表现不会差距太大.

数据恢复:每次压测系统时会产生新的数据,所以再次执行需要恢复数据,可以进行备份.或者环境清理.

load情况:top命令查,CPU出现排队情况,load不超过CPU核对*0.7,认为是合理的.

数据记录可以用nmon

linux剩余内存=free+bugger+cached

查看io命令:

loadrunner记录时间要比系统访问日志的时间多,因为包含网络传输,响应等时间.
CPU本身调度也会耗费时间.jmter超过线程不要超过100.

连接数:数据库,apache,缓存,cpu连接数等等.

测试报告:先跟架构师沟通,确认是否可以优化.

最好的优化都是架构上的优化