jmeter性能原理

简介

进程相当于马路，线程相当于汽车

  jmeter-server 分布式 每一台机器能创建多少用户数--内存（物理内存）

    jmeter 一个java进程，进程需要一定内存资源---堆内存

    JMETER_HOME PATH 两个路径的配置，输入jmeter，可以通过命令行打开jmeter，尽量不要用gui模式执行性能测试，因为会占资源

    jmeter语言的永久设置 在jmeter_properties文件中指定language为zh_CN

    在查看结果树里可以指定执行结果数据的保存文件

    聚合报告的tools下拉菜单有生成可以生成html报告的选项

    setup线程组 初始化  线程组  teardown线程组

    监控平台、性能瓶颈分析、真实环境联系、性能分析报告编写

    1个是功能 n个是性能，覆盖重要场景 从1到n

    漂亮的jmeter脚本：准确、快速、漂亮

    接口请求的获取：文档、抓包、jmeter代理录制脚本

讲解

对jmeter的测试计划右键，添加非测试组件的http代理，在浏览器的设置-高级-系统-打开计算机的代理设置，将代理地址改为本机的127.0.0.1 8888（这之前需要在浏览器设置中导入jmeter的证书在bin下），打开系统代理设置，并导入jmeter
bin目录下的证书文件。点击启动代理后，即可以开始录制。

>         jmeter4点几版本的不支持代理录制，录制的时候会报错
>         jmeter是多线程模式

    请求头管理器、cookies管理器、请求默认值、响应断言、错误请求的记录通过勾选察看结果树中的

    错误选项来看、聚合报告、用表格查看报告（可以看发起时间）、图形结果，根据实际需要选择查看器类型。可以选择返回结果的展示形式为jsonpath，方便查看。

    按照从上到下的顺序执行脚本，控件作用域与放置位置有关。

    前置处理器、后置处理器、分别指请求发之前和之后的处理器。比如加密 md5为前置，提取数据为后置。另外还有定时器、断言

    思考时间-固定定时器 每个请求中间加一个等待时间

    同步定时器-集合点 所有的请求集合好之后，高并发同时访问

    随机定时器-时间随机

    吞吐量定时器-分流效果

> 参数化技术，找到需要参数化的数据、准备数据源、将常量替换为变量。csv、函数式、随机数、time 时间戳、counter计数器、变量
> 即用户自定义的变量、编程式引入外部的jar、java、class、使用beanshell编程，用到数据文件最好放到bin文件下，这样方便他人使用不会存在路径问题。

>         json提取器，增加变量名，$.json的字段值
> 
>         报必须为中文错误时，将编码设置为utf-8
> 
>         函数生成器，可以生成随机变量表达式，点击生成后复制到对应的位置使用即可，如模拟手机号后8位信息的${__Random(1111111,99999999,)}关联技术，目的是提取，断言的主要目的是对比。
> 
> 
> 	正则表达式：()括起来的部分就是要提取的 .匹配任何字符 +一次货多次?不要贪婪，找到第一个就停止。
> 	如提取value="readme.txt" 的正则表达式为value="(.+?)"多个可以多次提取，$1$$2$分别代表第一个提取的值和第二个提取的值，提取到之后可以使用MYREF g g0  g1，在debug处理器中可以看到对应的取值 。
> 
>   获取html页面的title、response中的参数，通过添加debug处理器可以查看变量的取出情况。
>   synchronizing timer 同步定时器，可以形成集合点。在表格查看的记录中可以看到时间值是一样的，默认的用户数值0表示全部，超时时间为0表示没有超时时间。
>   用户数不能超过线程中设置的最大用户数，超过了就会一直等待。如果小于线程中的用户数，且达不到下一轮的集合用户数，就会出现一直等待的情况，
>   这种情况可以通过设置超时时间来执行最后的用户的集合点并执行结束该任务。

解释

> 仅一次控制器的加入，可以控制某些请求在一次线程里只请求一次。如线程的用户数为2，循环次数为2，那么每次循环，它只会执行一次，循环两次。

性能指标分析：多、快、好、省。功能讲究覆盖率，性能讲究高频，提取核心业务、高频业务、扎堆场景。了解业务场景、了解项目部署架构。
性能指标：用户数、响应时间、TPS、错误率、服务器资源。

>     性能场景指标：验证最大在线用户数--（负载测试逻辑） 错误率<5% 请求响应时间<5s 场景运行10分钟--不加同步定时器 服务器资源使用合理：cpu使用率<80% 内存使用率<80%
> 
>     如果遇到登录需要单点，那么就需要在数据库里面创建一批用户
> 
>     确认需要参数化的数据，准备好参数化的数据源，脚本中的常量改成变量。jmeter可以调用java开发的.class或.jar来进行加密计算。csv加密、函数加密、计数器加密。
> 
>     搭建监控环境、运行场景、监控与分析、性能调优、回归测试优化后的效果、测试报告。
> 
>     独立运行每个线程组选项不勾的时候，表示所有线程会一起执行，勾了就会逐个执行。
> 
>     用户自定义变量是全局的（整个测试计划通用），没有作用域，定时器、断言、监听器都是有作用域的。
> 
>     200请求成功 302重定向 404请求资源不存在 500服务器内部错误（如数据库挂了）
> 
>     如果请求2个接口中间要等待几秒，那么在第二个请求上加个固定定时器。
> 
>     持续时间和循环永远要搭配使用，否则持续时间不生效
> 
>     线程数除以ramp-up时间是每秒的并发数，teardown线程组的配置数量要和普通线程一样，setup的使用默认的就可以，勾选只显示错误，避免并发量大的情况下错误信息被刷掉。
> 
>     grafana性能监控 数据采集node_exporter 9100、mysql_exporter 9104、数据存储prometheus 9090、数据展示grafana 3000，具体搭建方法还未整理
> 
>     未做分布式的时候，不要压的太高，百来个就可以了。
> 
>     运行场景、看聚合报告 响应不符合要求，去grafana看，发现cpu占用率过高，sys、usr、idle、io中找到较高的是usr top指令
> 查看具体哪一个进程使用cpu高。在列表中的cpu看到的是多核cpu的占用之和，如4核的会达到将近400。数据库性能测试需要铺大量数据，否则是无法发现一些慢查询的性能影响问题。要找到对应的影响语句，show variables like '%query%';
> 查看数据库的慢查询打开情况，可以设置阈值，当运行后，可以记录具体的慢查询语句到日志文件中，通过语句查看慢查询具体的执行语句select *
> from mysql.slow_log ORDER BY start_time DESC LIMIT 100;
> 
>     top -H -p PID值，可以查看进程中每个线程的情况。
> 
>     java进程常见性能问题：线程死锁（代码行）、堆内存（对象）、GC、jar包，此外影响性能的中间件还有redis ngins tomcat mq，mysql 分库 分表是否合理  死锁（排斥锁、共享锁）

性能监控方案

性能监控方案：在服务器中安装性能数据收集器，传给收集器。serverAgent将serveragent-xxx.jar上传被测服务器解压，进入目录，windows双击serveragent.bat启动，
linux执行serveragent.sh（如果不是可执行的绿色状态，需要改为777网上查下怎么改），
默认使用4444端口，jp@gc会启动。在jmeter中对计划右键，
选择性能接收器jp@gc-perfmon metricscollector（是一个jmeter插件），
增加被监控服务器的ip和端口号，分别增加cpu和memory两项监听，
可以设置把监听结果记录到csv文件里面方便任务结束后查看。
nmon监控：离线方案，通过nmon收集器收集数据，等场景运行完成之后，
使用离线分析；实时方案，grafana+nmon_exporter，但不建议，因为有其他工具比这个好用。
解压并获取对应平台的nmon工具tar -zxvf nmon 16e_mpginc.tar.gz mv nmon_x86_64_centos6 nmon-重命名 nmon -s20 -c3 -f -m /usr/local/nmon_output
表示每20s采集一次数据，采集三次生成报告文件名包含文件创建的时间生成报告的存放目录，
对生成的日志文件离线导出后使用excel分析工具解析生成报告。
不好看海量和长期趋势。本机使用excel分析工具Nmonanalyser。grafana监控平台，比较经典，
选择监控方案需要具备的特性：准确性高、时效性好、可视化高、历史数据、警告通知

测试报告

测试报告需要有描述：

数据、结论。测试数据来自工具运行场景性能指标、服务器资源数据、对比结果数据。描述响应时间平均值、90%和95%的响应时间，是否要需求时间之内，2 5 8原则。可以查看仪表盘和图形报告，

jmeter报告导出：

jmeter -n -t test.jmx（脚本路径） -l report.jtl -e -o 报告文件夹 或者在图形界面中右键导出。 每次导出前需要清空之前的测试结果数据log、jtl否则会报错，使用命令行执行命令后，生成的报告比较漂亮的报告（html的）。

对于场景中的数据设置需要有描述如：

jmeter -n -t C:User\XinTian\Desktop\sqTest.jmx -l report.jtl -e -o C:\User\XinTian\Desktop\result。如果导出csv打开显示的是乱码，可以先改成txt格式，打开后另存为csv文件格式选择ansi。

 1. 测试报告是一个性能测试完成的里程碑，测试报告是整个性能测试环节的总结性工作：性能测试方案、场景、性能分析、结论。
        
2.性能测试报告关注人员。测试基本信息：测试目的、背景、范围、引用文档、报告目标读者、术语定义、参考资料。
        
3.测试环境描述：服务器软/硬件环境、网络环境、测试工具、测试人员、物理部署、测试机与被测服务器在同一局域网，排除网速限制和网速不稳定性。
        
4.测试案例执行分析：详细描述每个测试案例的执行情况，以及对应的测试结果分析。
        
5.测试结果综合分析及建议：对本次性能测试做综合分析，并给出测试结论和改进意见。
        
6.启动多少个进程，多少个线程，并发多少，项目日志开启info状态。
        
7.需求场景分析、性能指标、设计场景、执行场景、性能分析、编写测试报告、在通过性能指标时也需要关注下服务器资源指标，才能给后续的测试提供对比指标

8.cpu 内存 磁盘 网络 其他（数据库性能（连接池概念）、系统的分布结构）、性能分析、编写测试报告。
        
9.put的消息体格式与get post不一样，变量和值都写在值一栏中，且有链接符号&也需要到上一个参数后面