Jmeter 性能测试工具使用总结
jmeter概念及使用 1、创建线程组 通俗的讲一个线程组，可以看做是一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。 2、输入线程组名称 3、添加一个http请求，参数只需填写路径和请求参数即可 4、添加监听器“查看结果树” "查看结果树"监听器会展示采样器请求和响应的细节，还可以将测试数据导入到文件之中，以供后续分析，暂不考虑 5、点击执行，根据界面提示保存开发后的测试脚本 6、执行后查看结果视图，可以看到服务端返回的响应内容 7、添加断言用户可以使用断言来检查从服务器返回的响应内容。通过断言可以测试服务器返回的响应内容与需求是否相符 8、添加聚合报告 在用JMeter做测试的过程中，使用的最多的Listener就是这个聚合报告，对于每个请求，它统计响应信息并提供请求数，平均值，最大，最小值，错误率，吞吐量(以请求数/秒为单位)和以KB/秒为单位的网络带宽。 9、设置线程数，执行性能测试，查看性能测试报告 至此第一个（get请求的）压测接口脚本开发完成，并可以进行性能测试了，但聚合报告中的每一项有必要在这里解释下： Label:请求的名称，就是我们在进行测试的http request sampler的名称 Samples:发给服务器的请求数量5次，即 5线程数X1迭代数 Average:单个请求的平均响应时间，单位是毫秒 Median: 50%用户的请求的响应时间，中位数 90%Line:90%的请求的响应时间（即百位分数，这里指90%的请求响应时间都是小于XXms） 95%Line:95%的请求的响应时间（同理，这里指90%的请求响应时间都是小于XXms） 99%Line:99%的请求的响应时间（同理，这里指90%的请求响应时间都是小于XXms） Min:最小的响应时间 Max:最大的响应时间 Error%:错误率=错误的请求的数量/请求的总数 Throughput: 吞吐量即表示每秒完成的请求数 KB/sec: 每秒从服务器端接收到的数据量 jmeter的参数化，检查点，关联，集合，session，cookie，正则表达式 1、调试post接口 2、请求一次，保证接口能正常返回， 3、关联 & 正则表达式 后置处理器是JMeter的关联组件，可以从服务器响应数据中查找到需要的数据。常用的是正则表达式提取器（Regular Expression Extractor） a、创建正则表达式提取器，Regular Expression Extractor b、提取接口返回参数 c、添加后置处理组件中的BeanShell PostProcessor，并输出正则表达式提取的值到jmeter的log中 d、执行脚本，查看jmeter的log是否有提取的字符 到此本节基本算是完成，集合点在这里没有着重介绍，这里不做重点，工作中这块也用到较少，下面主要介绍正则表达的一些解释： （1）引用名称：下一个请求要引用的参数名称，如填写你nowtime，则可用KaTeX parse error: Undefined control sequence: \n at position 107: …项后停止。 注：(.+?)[.\̲n̲]+可以匹配换行符在内的所有字…引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的东东），则可以是$2引用起来，如果在正则表达式中有多个正则表达式（多个括号括起来的东东），则可以是$2,$3等等，表示解析到的第几个值给title。如： 1 1 1表示解析到的第1个值 （4）匹配数字：0代表随机取值，1代表全部取值，通常情况下填0，如果在LR中，取出的值是一个数组，还得处理一下，LR11版本用一个随机的函数就可以不用写大段的代码来处理数组。 （5）缺省值：如果参数没有取得到值，那默认给一个值让它取。 jmeter脚本开发调试过程中常见的请求类型及错误码 一、GET类型 一般都是通过Form表单提交，或者直接在url后面通过“？”连接入参 二、POST类型 POST请求分为2种类型，一种是Form表单类型（像上面GET请求一样），另外一种就是传入json，入参需要传入json格式的body。 a、Form表单类型入参 b、json类型入参（注意：需要在header中传入Content-Type：application/json） 还有一种基于SOAP协议的POST请求这里就不讲了（避免让大家绕进去），下面主要介绍下日常调试过程中经常遇到的错误码。 三、常见错误及解决方案 1、报错404 a、服务后台是否有这个接口存在 b、接口的path路径错误问题2、500 无法请求 a、后台：500报错一般是后台的问题。3、405 请求方式不一对 a、一般的解决方案是把post请求换成get请求，或者get换成post请求4、400 一般解决方案：看后台方法，写对参数及对应的值。 5、415 请求的格式不受请求页面的支持 一般解决方案：Form表单形式切换成json形式 415 6、502（错误网关）服务器作为网关或代理，从上游服务器收到无效响应7、504（网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求 jmeter原理介绍（加深对jmeter的理解） Apache Jmeter是Apache组织开发的基于JAVA的压力测试工具 Jmeter可以用于对服务器，网络或对象模拟巨大的负载，来自不同压力类别下测试他们的强度和分析整体性能。jmeter作为浏览器与web服务器之间的代理网关，可以捕获浏览器的请求和web服务器的响应，通过线程来模拟真实用户对web服务器的访问压力。jmeter是运行在java虚拟机上的，基本原理是建立一个线程池，通过线程组驱动多线程，多线程运行sampler产生负载，在运行过程中通过断言来验证结果的正确性，可以通过添加监听器（聚合报告、图形结果和查看结果树等）来记录测试结果 使用说明：
如果取样器中有参数化需求，可以通过配置元件或者前置处理器来完成；如果取样器中有关联需求，可以通过后置处理器来完成；如果要模拟负载场景，比如模拟多少用户，运动多长时间，可以通过线程组完成；如果要模拟并发场景，可以通过定时器来完成；（一般不不需要设置，定时器绝对并发这种场景有点不太符合实际业务场景）如果要控制业务的执行逻辑，比如登录只运行一次，可以通过控制器来完成； Jmeter结构体系： 把Jmeter的结构体系拆分为三维空间，如图： X1~X5：是负载模拟的一个过程，使用这些组件来完成负载的模拟；X1：选择协议，模拟用户请求，检查服务器响应是否正确，然后收集结果信息；X2：完善测试脚本部分，包括参数化，关联等；X3：控制测试脚本业务逻辑；X4：集合点，模拟用户并发；X5：用户数，一个线程代表一个用户；Y1：可以理解为选择协议，包含负载模拟部分，负责模拟用户请求；Y2：可以理解为检查点，结果验证部分，负责验证结果正确性；Z：可以理解为监控器，负责结果的收集，监听器不仅可以放在线程组之内，也可以放在线程组之外； jmeter聚合报告关键指标解析 外部指标： 从外部看，性能测试主要关注如下四个指标: 1、吞吐量：每秒钟系统能够处理的请求数、任务数。 2、响应时间：服务器处理一个请求或一个任务的耗时。 3、错误率：一批请求中结果出错的请求所占比例。 4、带宽：每秒从服务器端接收到的数据量（KB/s） 再回过头来看jmeter的聚合报告，以上4个指标均有体现，下面我具体来分析下： 1、响应时间：聚合报告中包含Average、Median、90%Line、95%Line、99%Line、Min、Max四个时间指标，它们的值越小效果越好，表示接口响应越快。但是在实际工作中我们一般会关注90%Line这个值，表示90%的响应时间是小于43ms，Average对应的平均响应时间参考意义不大，一般我们不参考这个值。 2、吞吐量：在聚合报告中是指Throughput这项（即TPS），表示服务器分秒处理请求数或任务数。该值越大越好，表示服务器处理能力越强。 3、错误率：聚合报告中是指Error%（错误率=错误的请求的数量/请求的总数），错误率越低越好，为0表示没有异常请求。对于一般业务来说错误率要在万分之一以下。考虑到不同业务的区别，这个万分之一的标准可能会有变化。 4、带宽：在聚合报告中指Recived(KB/s)，表示从服务器端接受返回数据所占网络带宽。这个值一般要求越小越好，越小占用带宽越小，间接的表示服务器端返回数据较小。一般内网环境也就是千兆带宽，如果该值过大时，需要考虑优化。 总结： 性能测试中，数据收集很重要，但是更重要的是快速抓住关键数据，读懂数据的含义。本文主要介绍了jmeter聚合报告中的几个关键指标。其他一些外在指标后续会慢慢介绍。大家在使用中如有问题随时可以私信。 性能测试概念和性能测试指标 性能测试概念和性能测试指标外部指标（业务指标） 从外部看，性能测试主要关注如下三个指标 • 吞吐量：每秒钟系统能够处理的请求数、任务数。 • 响应时间：服务处理一个请求或一个任务的耗时。 • 错误率：一批请求中结果出错的请求所占比例。 对于响应时间的统计，一般从均值、.90、.99、分布等多个角度统计，而不仅仅是给出均值。均值在实际工作中参看意义不大。 吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。 • 吞吐量越大，响应时间越长。 • 服务器硬件配置越高，吞吐量越大。 • 网络越差，吞吐量越小。 在低吞吐量下的响应时间的均值、分布比较稳定，不会产生太大的波动。 在高吞吐量下，响应时间会随着吞吐量的增长而增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。如图： 如图 错误率和服务的具体实现有关。通常情况下，由于网络超时等外部原因造成的错误比例不应超过5%%，由于服务本身导致的错误率不应超过1%。 内部指标（资源指标） 从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等，具体使用方法命令以及各参数含义后面在第二篇linux相关知识中介绍。 • cpu：后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利用率对服务的性能起着决定性的作用 • 内存：性能测试过程中对内存监控的主要目的是检查被测服务所占用内存的波动情况 • load：Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数。通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利用服务器大部分性能，又留有一定的性能冗余应对流量增长。 • 网络：性能测试中网络监控主要包括网络流量、网络连接状态的监控。 • 磁盘IO：性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致大量请求处于IO等待的状态，系统负载升高，响应时间变长，吞吐量下降。 性能通过标准 通过对以上内外指标（即业务指标和资源指标）了解，对于性能测试，在测试过程中需要通过观察这些指标，根据这些指标的结果来判断是否满足要求，主要包含如下图： 性能分析之可悲的响应时间 结论如下： 1秒是较好的的响应时间，记住是较好而不是最理想； 0.1秒是最理想的响应时间，因为0.1秒人是无感知的，而1秒会让人感觉到停顿，但是也是可接受的； 4秒是业务可以接受的上限，因为到了4秒的时候，客户流失率明显增加了； 10秒是完全不可接受的，因为已经导致企业的经济已经入不敷出了。 因此需要清晰的理解响应时间，它包含哪些部分。这会对于在性能测试复杂系统部署架构时，分析时间过慢的原因，定位有很大帮助。首先我们看张图： 响应时间定义：是指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。该定义着重强调的是所有数据都已经被呈现到客户端所花费的时间，为什么说是所有数据呢？因为用户体验带有主观性，用户认为从提交请求到服务器开始返回数据到客户端的这段时间为响应时间。因此，从严格意义上讲，“系统响应时间”加上“显现时间”，才是完整的用户感想到的响应时间。当然，呈现时间还有更深层次的理解，它还包括浏览器本身产生的时间、解析页面、渲染时间、用户反应时间等。 且日常性能测试针对后端接口测试的居多，且在呈现时间这块很难去优化，这就要求系统响应时间足够短，也就是要求后端接口响应时间足够快，用户体验才会更好。 性能分析之用户数/响应时间/TPS的关系 术语定义 虚拟用户：性能测试中通过线程或进程执行脚本来模拟典型用户访问系统行为的用户。 TPS: 每秒处理事务数, 是衡量系统性能的一个非常重要的指标。 在线用户（或活跃用户）：一个时间段内，与服务器保持交互的用户，也称为活跃用户。需与论坛或者QQ上常见的“在线人数”定义区分，该类系统的在线用户不一定是活跃用户，在线只是一种状态。但在业务类系统中，一般只考虑活跃用户，可认为与在线用户通用。 并发用户：表示同一时间与服务器保持交互的用户。 响应时间：简称RT,指的是业务请求从客户端发起到客户端接收服务器端响应请求完成的时间。 思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。 在线用户数和并发用户数的区别 下图中红色表示访问首页操作、黄色表示访问投票页面操作、橄榄色表提票提交操作、绿色表示投票统计结果查看操作、蓝色表示“等待行为”。“等待行为“是什么呢？比如用户在页面填写内容、浏览页面信息、浏览统计结果数据，这些用户在客户端行为与服务器无任何交互，对服务器来说是没有负载压力的。 我们可以从图中看出25个用户在线访问投票系统，每个用户操作流程是1访问首页、2浏览首页、3访问投票页面、4填写投票表单内容、5投票提交、6投票统计结果查看访问、7、浏览统计结果。其中1、3、5、6操作会与服务器进行交互，对服务器形成负载压力，而2、4、7操作是用户在客户端的行为，并没有与服务器进行交互，对服务器没有任何压力。 从时间视角1来说，当前活跃用户数（在线用户）是25、并发用户数只有7个，为什么呢？因为从当前视角来看只有7个用户在同时与服务器进行交互，对服务器形成了负载压力，而其他18个用户都在“等待行为”状态。 那么从视角2来看，活跃用户数（在线用户）仍然是25，并发用户数是多少呢？答案是6个。 所以我们在虚拟用户在模拟用户行为的时候，如果虚拟用户中包含“等待行为”的话，那么虚拟用户数=在线用户数；不包含“等待行为”的话虚拟用户数=并发用户数。 虚拟用户数、响应时间、TPS之间的关系 在术语中解释了TPS是每秒事务数，但是事务是要靠虚拟用户做出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。 由此我们可以一个公式： TPS=虚拟用户数/响应时间 通常针对服务器端的性能评估，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。 施压策略建议 通过很多性能测试案例，发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。另外咨询很多专家做过的性能测试项目，基本都没有超过5000用户并发。 因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。 在做负载测试的时候，一般都是按照梯度施压的方式去增加虚拟用户数，而不是在没有预估的情况下，一次加几万个用户，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义。 总结 • 系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。 • 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。 • 建议性能测试的时候，不要设置过长的思考时间或不设思考时间，以最坏的情况下对服务器施压。 • 一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了 性能场景之数据 在性能测试过程中，免不了要造一些参数化数据，测试数据的设计及准备在性能测试过程中至关重要。它的成败直接关乎到压测结果是否有意义的。比如压测接口返回数据量过大的话，带宽可能会占用较大，接口RT可能过长；测试数据如果不均衡可能会导致TPS浮动比较大等。首先我们通过一个架构图： 一个请求过来打到网关，网关分发到对应的服务器，服务器根据接口内部逻辑去查询DB或者redis 这个架构图在现实工作中应该是再简单不过的了。通过架构我们能够直观的看到跟数据相关的2点： • DB中包含的数据量（铺底数据），数据类型、各状态分布等 • redis中的各种类型的key、value大小、数据量大小（占内存）等 在执行场景之前，需要知道它们里面的数据状态，比如我们不能使用一个空库去做压测或者使用过小的value去做压测。如果数据不合理，接口性能不能真实表现出来，做了也是白做，还可能会跟研发留下不靠谱的影响。那么如何使测试数据合理呢？毋容置疑，使用真实的测试数据。 但是在实际过程中，大多还是需要我们自己去生成测试数据的（比如：新功能的迭代，这些数据线上本身就没有，而你又不能等上线后再去测试）。那么就必须造出符合业务规则的数据，一般有以下几种方式：在数据库中插入数据（可以使用存储过程、sql、程序等）通过业务生成（前端操作、或业务接口）使用生成环境脱敏数据（如果有条件的话，尽量用） 测试数据在性能测试过程中是相当重要的一个环节，考虑的因素比较多，需要综合各方因素进行分析，才能测试出被压接口的真实性能水平。这个需要大家在工作中要格外注意，可以慢慢积累。随便推荐下《Mysql 快速创建千万级测试数据方法》 性能分析之性能建模 性能测试策略 通过很多性能测试案例，发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。跟业界一些性能测试专家交流，接触的性能测试项目，基本都没有超过5000用户并发。 因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。 在做负载测试的时候，一般都是按照梯度施压的方式去增加虚拟用户数，而不是在没有预估的情况下，一次加几万个用户，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义。 1、基准测试 单用户测试，目的是为其他测试提供参考依据； 建议单用户循环多次得到的数据，避免单独请求一次的结果（这有偶然性） 2、并发测试 模拟客户端请求，在单位时间内(S)同时发起一定量的请求，验证系统是否具有并发性的问题。 3、负载测试 不断增加请求压力，直到服务器某个资源项达到饱和（比如CPU使用率达到90%+）或某个指标达到安全临界值（比如运维的监控告警阈值or拐点）； 负载测试（也叫阶梯式压测）一般主要用来寻找性能的拐点，验证系统在既有测试环境不同的请求压力下能否正常运行。 4、容量测试 采用负载测试策略，验证在现有测试环境下被测系统的最大性能表现（可接受的最大性能表现，不一定是最优性能表现）。 5、极限测试 在既有测试环境下，不考虑资源占用率的极限情况（CPU使用率达到95%以上或IO异常繁忙或Load值较高），在系统不宕机的情况下的最大处理能力。 PS：由于被测系统的业务场景各不相同，这种策略，采用率相对较少。 6、配置测试 不断调整系统各方面的配置（软硬件、参数配置等），验证在性能达到最优时（最优的性能一定是权衡各方面因素找到的平衡点）的最佳配置。 7、浪涌测试 验证系统在某段时间内并发突增或请求量波动较大的情况下，系统能否正常稳定的提供服务。 PS：这种测试策略使用的也相对较少，主要针对不确定性的短期的峰值流量涌入场景（比如某微博的离婚、恋爱、分手话题）。 8、稳定性测试 以恒定的并发数（根据负载测试的结果，CPU使用率在70%时对应的并发数），验证系统在混合场景下的性能表现。 9、批处理测试 验证待测系统在既有环境下，系统的批处理（一般都是一个crontab或者触发式的job）业务能力能否满足生产的业务需求指标。 10、高可用测试 在集群多节点或分布式的情况下，破坏其中一个或多个集群节点，验证系统能否及时恢复服务能力。 11、容错恢复测试 验证系统能否在出现故障的情况下仍能保持正常提供服务的能力或出现故障后的自我恢复能力。 徐毅推荐的其他性能测试工具 wrk，ect 性能测试阶段 在实际工作，一般我们会从这么几个阶段开展性能测试。 1.环境 开始性能测试前首先需要有个独立的压测环境，各服务调用尽量走内网（排查网络环境），尽量不要使用测试环境，一般公司测试环境从节约成本角度，配置较低或者混着部署（一台机器上部署了N多个服务），压测的时候几个并发就可能把资源消耗完，根本压不起来，间接掩盖了程序存在的性能缺陷。我当前的公司有独立的线上内测环境、测试环境、压测环境，压测环境的机器配置（硬件、软件参数）是根据线上服务器配置保持一致，基本配置（4C8G）。环境这一步还是较关键的，机器不给力或者配置有差异，后面得出的压测结果可信度可想而知，研发也不会认的。 2.测试确认 确认测试范围，了解被测接口内部逻辑、是否存在特别需要关注的点、测试数据量等。一些重要信息需要同产品、研发、业务测试人员讨论确认，如用户最常常用是哪些场景（是必填居多还是非必填居多）、最关注哪的性能，哪些数据需要模拟到真实的量级等。 3.设计测试 包括根据实际业务场景设计测试用例、准备测试数据。这就涉及到上面提到的测试确认信息，用户的使用习惯、工作时间段、系统各模块压力分布等等。只有场景设计到位（比如：一个接口所有参数是非必填的，你压测的时候如果都按照必填去测话，场景就跟实际不一致了），才会让压力结果才更有意义，更能暴露出系统存在的瓶颈。同时，测试数据准备也是很关键的一步，生成测试数据量达到未来预期数量只是最基础的一步，更需要考虑的是数据的分布是否合理，需要仔细的确认程序中使用到的各种查询条件，这些重点列的数值要尽可能的模拟真实的数据分布，否则测试的结果可能是无效的。 4.执行测试、监控 准备测试脚本，执行之前设计好的各个用例，监控并收集需要的数据。由于日常主要是迭代版本优化测试，这里简单介绍下压测场景：针对设计好的测试用例，每一种情况，我们会进行4组测试，比如：基准测试（单用户迭代100次）、50并发一次、100并发一次、100并发持续5分钟这四种情况。在这个过程中，我们会对每一种情况收集相应的测试数据和监控数据，若有问题出现时，会结合这些数据对问题进行分析定位。 5.通过标准 性能测试前提还需要有个标准，这个是衡量性能好坏的关键指标。由于是日常迭代版本压测（主要是单接口压测），我们内部考虑到用户可接受的业务指标和资源指标定了个标准： 这也是很多刚接触性能测试时比较迷茫的地方，不知道压到多大压力才算满足自己需求的。 6.测试报告 将测试过程中各种数据（业务数据、资源数据）收集起来汇总成报告，展示给各方人员看。这里我附上我们日常单接口压测的一个报告。 有了标准，我们就能确定哪些接口是通过性能标准，哪些是不通过标准的。至于不通过标准是什么原因导致的这个就牵涉到分析、定位问题。这属于一定的技术能力，牵涉的知识面较广，后续介绍。