jmeter

背景 随着业务不断发展，用户量不断增加，系统负载越来越高。为了解决系统负载问题，我们是不是直接大量增加机器就可以了？ 同时，公司业务开展需要，可能需要开展各种营销活动，目前系统是否能够支持那么多用户也是个未知数，如何解决呢？ 答案就是今天要讲的压测。 目的 验证单个业务及整个的处理能力及响应时间等 验证系统的性能瓶颈 合理的容量规划，而不是大量增加 分类 单接口压测 全链路压测 性能测试指标 业务类 TPS 相应时间 - 平均响应时间、最小响应时间、最大响应时间、90%响应时间等 - 百分位数是一个统计学名词。99% 的百分位响应时间，指的是 99% 的请求响应时间都处在这个值以下。 - 如果99%响应时间跟平均响应时间相差很大，那么说明是抗不住这么大量的，需要做相应调整及优化 业务成功率 - 压测前要确定压测的业务成功率，不能把报错的数据当做压测结果，一般可以定业务成功率最少为1% 系统资源指标 CPU使用率 内存使用率 磁盘繁忙率 网络IO 全链路压测 目的 只做单系统压测是不够的，因为在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。 为什么选择线上环境做全链路压测

问题 ​ 压测时发现系统的瓶颈在于cpu，那么考虑为啥瓶颈在cpu，以及如何优化？ 发现过程 ​ 测试环境使用jmeter进行接口压测，然后逐步调大并发度，观察系统吞吐量，然后在ares平台（类似skywalking）上监测JVM内存，CPU，线程状态等 ​ 然后发现，gc信息和内存信息很稳定，但是cpu会达到90%，这时查看jvm的线程状态，发现又70%左右的线程处于waiting或者timed_waiting状态； ​ 初步推算会不会是线程过多导致cpu过高。 问题分析 首先分析接口的执行流程以及线程池的使用场景 简单的描述一下：客户端发来一个请求，由容器线程接收，然后通过common线程池创建多个线程去并发执行，然后通过latch进行等待，等所有的common线程执行完在合并然后返回给客户端；每一个common线程是一个小任务可以称为“单品查佣”，common线程会首先使用select线程池创建4个并行任务进行参数转换，并且通过latch进行等待然后合并，紧接着继续并发进行查询，此时也是使用select线程池先去并发查询然后再common线程里面合并计算结果。 上图颜色相同的表示在同一个线程或者线程池，通过上图可以大概得出common线程池和select线程池线程个数比为1:5（是不是真的这么去设置线程池大小呢？）。 希望本文对你有所帮助，加入我们，了解更多

背景： 在用JMeter写接口case，遇到一种情况，接口1查看列表接口，接口2查看详情接口，接口2需要传入接口1列表的第一条数据的id 因为这个id后面我可能会改变，所以也不适合作为全局变量来设置 解决方案： 首先放一下总体截图 具体步骤 1-新建一个Thread Group即线程组，在该线程组下面添加接口1的HTTPrequest，填写路径方法和参数等（选择线程组右键-add-HTTPrequest） 2-选择接口1的HTTPrequest ，右键新建一个正则表达式提取器，即上图中的“提取id” 3-在结果树观察列表接口的返回值，确认正则表达式 "content":\[\{"id":"(.+?)"能够获取到第一个id 4-将正则表达式和id补充到提取器的正则表达式内， 注意要勾选验证区域！否则会搜不到 ，我们这里是查看返回值，选择了Body 引用名称：下一个请求要引用的参数名称，如填写id，则可用${id}引用它 模板：用$*$引用起来，表示解析到的第几个值，如：$1$表示解析到的第1个值 匹配数字：0代表随机取值，1代表第一个，-1代表每一个 5-在线程组下，新建一个 Debug Sampler（新建路径：右键新线程组 - 添加 - Sampler - Debug Sampler），方便查看所提取的环境变量值是否正确 6-在当前线程组下新建一个接口2的HTTPrequest

如果你想从头学习Jmeter，可以看看这个系列的文章哦 https://www.cnblogs.com/poloyy/category/1746599.html Charts 介绍 包含了各种 详细信息图表 ，比 GUI 模式的图表好看且易懂多了！ 做性能测试，如何发现是否有性能瓶颈？必须从结果图表中找到鸭！ 而 html 报告将性能测试可能需要用到的图表都加进去了，可谓是6666 一共有三大模块 Over Time Throughput Response Times Over Time 一共有 6 个图表 Response times Over Time Response times Percentiles Over Time Active Threads Over Time Bytes throughput Over Time Latencies Over Time Connect Time Over Time =======>>>> 点击右侧即可跳转对应图表哦 Response times Over Time 脚本运行期间，不同事务（请求）的响应时间变化趋势图 包括 事务控制器 样本结果 重点： 可以根据响应时间和变化和TPS以及模拟的并发数变化，判断性能拐点的范围 一条线代表一个事务（请求） Response times Percentiles Over Time

准备： 1、MySql的驱动jar包：mysql-connector-java-5.1.28.jar， 2、jmeter安装目录中修改编码格式：\bin\jmeter.properties ：sampleresult.default.encoding=UTF-8 3、连接数据库的连接地址、用户名、密码以及操作sql语句 准备好 步骤一：下载MySql的驱动jar包 如果自己有，忽略这个步骤。 1、打开下载地址：https://dev.mysql.com/downloads/connector/j/，如下图，选择Platform Independent，然后根据情况下载，我下载的是zip包进行解压。 2、解压后，将mysql-connector-java-版本号.jar 包 放到Jmeter安装目录 \lib\ 下。 建议重启下Jmeter 步骤二：修改编码格式 jmeter安装目录 \bin\jmeter.properties ：sampleresult.default.encoding=UTF-8 步骤三：添加脚本 1、测试计划下 新增 JDBC Connection Configuration 2、新建线程组 ----> 新建样例 -----> JDBC Request，新增一个 结果观察树 和 Debug Sampler 3、设置 JDBC Connection

前言 在 linux 上执行jmeter 代码的时候遇到一个问题：There is insufficient memory for the Java Runtime Environment to continue. 报错内容 在 windows 先执行过 get_info.jmx，正常运行，传到 linux 上运行时遇到以下问题 [root@VM_0_2_centos ~]# jmeter -n -t get_info.jmx -l get.jtl OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000c0000000, 1073741824, 0) failed; error='Cannot allocate memory' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 1073741824 bytes for committing reserved memory. # An error report file with more information is saved

高级软件测试工程师应该具备哪些技能和知识，川石哥带你了解相关技能与知识。 Linux环境搭建及命令 1.虚拟机的搭建与使用 搭建虚拟机的操作步骤 搭建虚拟机系统环境 虚拟机的基本操作与使用 2.Linux系统安装，搭建测试环境 使用虚拟机，安装Linux系统 熟悉Linux系统，了解基本操作 Linux系统下搭建测试环境 3.Linux的基本语法和命令 熟悉Linux执行环境，以及常用命令 Linux相关拓展 4.Linux环境下搭建测试环境 Linux环境下安装数据库 Linux环境下安装jmeter Linux环境下安装缺陷管理工具 接口测试工具 接口测试神器，你绕不开的强大工具：Jmeter。小巧灵活：Postman Jmeter接口测试入门：Jmeter简介，环境准备，目录结构介绍，如何录制脚本，以及基础组件的使用，线程、作用域、HTTP请求、定时器、断言等等 Jmeter接口测试进阶使用：Jmeter逻辑控制、前置处理器、后置处理器、监视器、结果树，如何参数化、正则表达式关联、事务、检查点等等。并带领大家对带有token等动态数据的项目进行实战演练 Jmeter接口测试高级功能：Jmeter脚本思考时间、随机时间、线程启动间隔、并发集合点、联机远程调用，webservice、websocket、jdbc、命令调用等等 Postman接口测试工具使用：行业标准HTTP

性能测试中最容易被误解的部分之一就是 负载测试 。大多数人认为所有性能测试就是负载测试，但这是不准确的。有许多类型的测试组成 性能测试 。在进行负载测试之前要考虑的问题之前，让我们仔细研究一下负载测试的基本信息。 LoadRunner 的基本一种定义： 负载测试是许多并发用户运行同一程序，以查看系统基础结构是否在不影响功能或性能的情况下处理了负载。 还有一种说法将 负载测试 解释为： 负载测试是性能测试的子集。比如说性能测试相当于 Microsoft Office ，而负载测试就是 Word 。 Word 只是 Office 的一个组成部分。 Word 与 Excel 一起被大量使用。它们可能是 Office 使用最频繁的两个组件。 以下是准备进行负载测试时要考虑的N种策略。 针对正确的测试量 首先，不要在没有实际需要的情况下进行大规模测试。无需向软件施加超出实际预期的压力。 当然产生环境比预期拥有更高的流量负载始终是一件好事，但要保持现实和高效，应该专注于评估应用程序在生产中将遇到的正确工作负载。 以方便取决于周期性性事件，网站或APP可能会在一个以上高峰或高峰负载时间内遇到流量峰值。但是建议在着重负载测试之前首先通过模拟或者监控正常一天的吞吐量来开始负载测试。 这里的关键词是 吞吐量 ，这是另一个经常被误解的性能测试。系统吞吐量是指系统在单位时间内所处理的信息量

一. 前言 作为有点经验的码农，现在退休在家带孩子。闲来无事，想对使用过的框架（如果写语言容易引战，php是世界上最好的语言)做一个性能测试。 二. 背景 由于毕业后刚开始接触的编程语言是C#, 从aspx时代至mvc3, mvc4， 后来又出来netcore，见证了C#的掘起和没落（至少国内大环境不理想)。 由于大厂的示范效应加上java开源免费（现在oracle也要授权了)，生态极好，所以使用spring boot开始编程，说实在的(不要喷),我个人还是比较喜欢C#,因为语法糖太好用了， lambda，匿名函数匿名类，各类型之间的比较...。 由于nodejs的发明，使js变成前后端通吃的一门语言，异步单线程，事件驱动，适用于高并发的场景。 对于接触过的这些语言，我个人最喜欢js，因为弱类型，灵活。。。至于好或者不好，仁者见仁吧。平时一直在做码农也没时间去自己测试各种性能，现在正在赋闲，来测试一下我使用过的几个框架性能，也做一下比较。 三. 框架说明 1. java现在最流行的web框架应该就是spring的全家桶套餐了，关于数据连接，我个人喜欢使用orm, 所以使用springboot + jpa 2. netcore使用自己的mvc框架，数据库使用nhibernate, mvc+ nhibernate 3. nodej 使用egg + typeorm 四. 测试环境 1.