jmeter性能测试及性能调优PPT

Contents,目录,1,2020/5/9,Contents,目录,一.性能测试实施流程介绍1.了解什么是性能测试2.性能测试流程3.性能测试常见类型4.常用性能测试工具分类,2,2020/5/9,1.性能测试里论:性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能是衡量在一个环境下运行一个或多个应用程序的效率主要的指标一般是响应时间，tps，交易成功率2.性能测试流程:,3,2020/5/9,3.性能测试常见类型：,4,2020/5/9,4.常用性能测试工具分类：.LoadrunnerLoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周.JmeterJMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。这个工具相对于上面的LoadRunner来说，是比较轻量级的工具，便于安装且免费开源。不仅可以进行功能测试也可以进行性能测试，一般可以用来做接口测试。这款工具学习起来也非常的容易，只要用这个工具做过几次测试，就可以非常熟悉的运用了。,5,2020/5/9,Contents,目录,二.性能测试脚本介绍1.事务2.参数化3.断言4.关联5.集合点6.思考时间,6,2020/5/9,1.事务：用户自定义的一个标识，用来衡量不同的操作所花费的时间，事务时间反映的是一个操作过程的响应时间。,7,2020/5/9,2.参数化：参数化作为测试脚本中最基本的使用技巧，需要每个从事性能测试的小伙伴都能熟练掌握。在测试工具中，每一个模拟用户都是一个线程，而在我们的仿真模型里，每一个用户都应该是一个真实的业务实体，每个用户代表的业务含义、他可以去处理的业务以及在处理业务的过程中可以操作的数据都应该是不同的，这样才可以更真实的表达现实世界中系统使用的负载模型。为了达到这个目的，将测试工具的每一个线程和仿真模型中的每一个用户及操作对应起来，就需要使用到参数化的脚本处理。说的有些太严肃了，简单举个例子，比如我们要测试用户注册的功能，注册的用户名是不允许重复的。我们录制完的脚本都是hardcode，直接进行并发测试的话，无疑所有模拟用户的线程在注册的时候输入的都是相同的用户名和密码，这样肯定是会有很多错误请求无法达到服务端，也就不能产生我们预期的负载压力。这时候，针对用户名就需要我们使用参数化的技巧来实现，每个注册的用户每次注册都使用不同的用户名来填写注册信息。,8,2020/5/9,3.断言:jmeter中有个元件叫做断言（Assertion），它的作用和loadrunner中的检查点类似；用于检查测试中得到的响应数据等是否符合预期，用以保证性能测试过程中的数据交互与预期一致。使用断言的目的：在request的返回层面增加一层判断机制；因为request成功了，并不代表结果一定正确。3.1.断言与beanshell组合使用.首先存储一个接口的响应结果.变量存储好后，再需要断言的接口后面添加BeanShell断言，使用Failrue来标识断言失败，FailureMessage标示断言失败的原因，,9,2020/5/9,4.关联（correlation）：在脚本回放过程中，客户端发出请求，通过关联函数所定义的左右边界值（也就是关联规则），在服务器所响应的内容中查找，得到相应的值，已变量的形式替换录制时的静态值，从而向服务器发出正确的请求，这种动态获得服务器响应内容的方法被称作关联。,10,2020/5/9,5.集合点：集合点用以同步虚拟用户，以便恰好在同一时刻执行任务。在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，从而达到测试计划中的需求。jmeter也是，NumberofSimulatedUserstoGroupby的意思是分批执行请求。当线程数到达设置的数量后，才开始发送请求。例如设置为5，如果启动的线程数到了4是不发送请求的，之后当再启动一个线程，线程数为5的时候才开始发送请求。这样就相当于设置了集合点。只有达到我们想要的并发线程数的时候才开始并发。如果我们的并发线程数为10，那我们就可以设置线程组的线程数为10，加个SynchronizingTimer，设置为10就可以。Timout的意思是等待请求多久后，不管线程数有没有到达设置的并发数量都开始运行测试。,11,2020/5/9,6.思考时间：用户自定义的一个标识，用来衡量不同的操作所花费的时间，事务时间反映的是一个操作过程的响应时间。Pacing：请求和请求之间的间隔先明确一些概念：1）定时器是在每个sampler（采样器）之前执行的，而不是之后；是的，你没有看错，不管这个定时器的位置放在sampler之后，还是之下，它都在sampler之前得到执行。2）定时器是有作用域的；当执行一个sampler之前时，所有当前作用域内的定时器都会被执行；3）如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入；4）如果希望在sampler执行完之后再等待，则可使用TestAction；一、固定定时器（ConstantTimer）毫无疑问，这是最重要的定时器。需要注意的是，固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间。如下图，固定定时器的时长设为300毫秒。定时器时长并不计入java请求的响应时间，但被计入“事务控制器”的总时间如果你坚持看到这里，并且对loadrunner的thinktime和pacing这两个概念还有记忆的话，我们可以有答案了：对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing；对于“事务控制器”来说，定时器相当于loadrunner中的thinktime。我们通常说的响应时间，应该大部分情况下是针对某一个具体的sampler（http请求），而不是针对一组sampler组合的事务,12,2020/5/9,Contents,目录,三.性能测试运行及监控介绍1.性能测试脚本的运行2.性能测试资源的监控,13,2020/5/9,1.性能测试脚本的运行：1.1.性能侧测试几种类型的设置：.基准测试的设置：.负载测试的设置：.混合场景的设置：,14,2020/5/9,1.2.2第二种：负载运行：由于jmeter是java写的，效率没loadrunner那么好，loadrunner是c语言写的.Jmeter是有一台主控机来控制很多的负载机，client主动去连server,server只要打开一个服务就行，脚本放在主控机上的，就是是这样的一个过程。Saver上必须先安装jmeter工具，然后改下配置文件。修改配置文件如下：在bin下面找到一个文件properticscdapache-jmeter-3.2/cdbin./jmeter-server假设，我的脚本里线程设置100，那么3台每台Saver就300.Loadrunner可以每台机器单独设置，但jmeter不行2、在控制机执行分布式命令jmeter-n-ttestplan/comic.jmx-r-ltestResult/result1.jtl启动所有从机执行脚本,15,2020/5/9,2.性能测试资源的监控：2.1安装工具nmon:(我这边有下载的工具及安装步骤）2.2用nmon监控工具收集后台资源收集命令：./nmon_x86_64_centos6-f-s6-c30说明：-f以文件的形式输出，默认输出是机器名+日期.nmon的格式，也可以用-F指定输出的文件名，例如:-s是采样频率，隔多长时间收集一次，这里我指定的是6秒一次；-c是采样次数，一共要收集多少次，这里我指定的是30次。2.3用nmon分析工具形成图表形式的文档分析工具：,16,2020/5/9,Contents,目录,四.性能测试分析介绍1.操作系统性能监控分析（cpu，内存，磁盘io）2.jvm堆模型，gc垃圾收集监控分析3.tomca(中间件）监控分析4.针对错误提示信息的分析,17,2020/5/9,1.1.cpu:单线程死锁这个判断流程比较多，生产上基本不会有问题，,18,2020/5/9,1.2.查看cpu利用率比较高的线程实现：,1.L,19,2020/5/9,1.3.cpu常用命令详解：uptime：满足什么会于运行对列：1.没有在等待i/o操作的结果2.没有主动进入等待状态（没有调用“wait”）3.没有被停止（等待终止）,L,20,2020/5/9,1.3.cpu常用命令详解：top：,L,21,2020/5/9,1.3.cpu常用命令详解：top：,L,22,2020/5/9,buffer和cache的作用是缩短i/0系统的调用的时间，比如读写等，一般一个系统而言，如果cache的值越大，说明cache住的文件数多，如果频繁地访问文件都能被命中，很明显会比读取磁盘调用快，磁盘的io必定会减小。cache的命中率是关键，如果频繁访问的文件不能被命中，对cache而言是个比较大的资源浪费，此时应考虑dropcache并且提升对应的cache命中率。命令：Free-msyncEcho3/proc/sys/vm/drop_caches,L,23,2020/5/9,1.2.内存：,24,2020/5/9,内存使用率：内存使用率=（1-空闲内存/总内存大小）*100%或内存使用率=（总内存-空闲内存-cached缓存-buffers缓存）/总内存内存使用率：无性能压力：0%50%、有一定性能压力：50%70%、达到性能阀值：70%80%、严重性能问题：80%100%内存使用率长时间处于95%以上-P1级bug内存使用率长时间处于90%以上-P2级bug,25,2020/5/9,1.2.磁盘：IO瓶颈往往是我们可能会忽略的地方（我们常会看top、free、netstat等等，但经常会忽略IO的负载情况），今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈，以及可能优化、定位的点。先来看一台典型的IO密集型服务器的cpu统计图：,26,2020/5/9,可以看到，CPU总使用率不高，平均1.1%，max到5.6%，虽然大部分都耗在了iowait上，但才百分之五左右，应该还没到瓶颈吧？,这里要特别注意：iowaitIO负载，要看真实的IO负载情况，一般使用iostatx命令,$iostatx1avg-cpu:%user%nice%system%iowait%steal%idle0.040.000.044.990.0094.92Device:rrqm/swrqm/sr/sw/srsec/swsec/savgrq-szavgqu-szawaitsvctm%utilsda0.0081.00104.004.0013760.00680.00133.702.0819.299.2599.90sda10.000.000.000.000.000.000.000.000.000.000.00sda20.000.000.000.000.000.000.000.000.000.000.00sda30.000.000.000.000.000.000.000.000.000.000.00sda40.000.000.000.000.000.000.000.000.000.000.00sda50.0081.00104.004.0013760.00680.00133.702.0819.299.2599.90,27,2020/5/9,这里重点指标是svctm和util这两列svctm指的是“平均每次设备I/O操作的服务时间(毫秒)”%util指的是“一秒钟I/O操作的利用率，或者说一秒中有多少时间I/O队列是非空的。”我们这里发现%util已经接近100%，可以知道其实目前这台服务器的IO已经到达瓶颈了。,那为什么最前面的cpu统计图的iowait项只有5.5%左右呢？因为这个iowait（也就是top里的wa%）指的是从整体来看，CPU等待IO的耗时占比：%waiowait也就是说，CPU拿出一部分时间来等待IO完成（iowait），但从磁盘的角度看，磁盘的利用率已经满了（util%），这种情况下，CPU使用率可能不高，但是系统整体QPS已经上不去了，如果加大流量，会导致单次IO耗时的继续增加（因为IO请求都堵在队列里了），从而影响系统整体的处理性能。,确认了IO负载过高后，可以使用iotop工具具体查看IO负载主要是落在哪个进程上了。,28,2020/5/9,详解iostat命令,29,2020/5/9,rrqm/s:每秒进行merge的读操作数目。wrqm/s:每秒进行merge的写操作数目。r/s:每秒完成的读I/O设备次数。w/s:每秒完成的写I/O设备次数。rsec/s:每秒读扇区数。wsec/s:每秒写扇区数。rkB/s:每秒读字节数。wkB/s:每秒写字节数。avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。avgqu-sz:平均I/O队列长度。await:平均每次设备I/O操作的等待时间(毫秒)。svctm:平均每次设备I/O操作的服务时间(毫秒)。%util:一秒中有百分之多少的时间用于I/O操作(使用率)或者说一秒中有多少时间I/O队列是非空的。,30,2020/5/9,如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。await:await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。如果svctm比较接近await，说明I/O几乎没有等待时间；如果await远大于svctm，说明I/O队列太长，应用得到的响应时间变慢，,r/s+w/s类似于交款人的总数平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数平均服务时间(svctm)类似于收银员的收款速度平均等待时间(await)类似于平均每人的等待时间平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少I/O操作率(%util)类似于收款台前有人排队的时间比例。,31,2020/5/9,2.jvm堆模型，gc垃圾收集监控分析,32,2020/5/9,内存的溢出:OutOfmemoryJava虚拟机中的OOm内存的溢出可能有两种：1.代码写的不好2.堆内存分配的太小了此处代码演示-Xms20m-Xmx20m-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=C:/,33,2020/5/9,34,2020/5/9,2.2堆内存的重点：,35,2020/5/9,这里有两点：GC:不会导致java程序的暂停，快速的收集下就可以了FULLGC:但是一旦发生fullgc，java里有一个非常重要的概念stoptheword，用户的线程就全部胡暂停了。假设在大量并发时，在大量的fullgc，用户的线程暂停了，就会影响速度。这里经历了两次fullgc任然不能回收，就内存溢出了,36,2020/5/9,DefNew:年轻代，串行垃圾回收器5478K-640K(6144K):执行前，之行后，(6144K)新生代最大的大小0.0205187secs：所花的时间Times:user=0.02sys=0.00,real=0.02secs：回收时,用户占了多少时间，系统太占了多少时间，真实的人的感受时间Tenured：老年代回收Metaspace：永久代回收Fullgc:整个堆回收,37,2020/5/9,命令行工具：Jstatjmp,38,2020/5/9,主要看FGC，值不能太大,39,2020/5/9,S0C：年轻代中第一个survivor（幸存区）的容量(字节)S1C：年轻代中第二个survivor（幸存区）的容量(字节)S0U：年轻代中第一个survivor（幸存区）目前已使用空间(字节)S1U：年轻代中第二个survivor（幸存区）目前已使用空间(字节)EC：年轻代中Eden（伊甸园）的容量(字节)EU：年轻代中Eden（伊甸园）目前已使用空间(字节)OC：Old代的容量(字节)OU：Old代目前已使用空间(字节)PC：Perm(持久代)的容量(字节)PU：Perm(持久代)目前已使用空间(字节)YGC：从应用程序启动到采样时年轻代中gc次数YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)FGC：从应用程序启动到采样时old代(全gc)gc次数FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)GCT：从应用程序启动到采样时gc用的总时间(s)NGCMN：年轻代(young)中初始化(最小)的大小(字节)NGCMX：年轻代(young)的最大容量(字节)NGC：年轻代(young)中当前的容量(字节)OGCMN：old代中初始化(最小)的大小(字节)OGCMX：old代的最大容量(字节)OGC：old代当前新生成的容量(字节)PGCMN：perm代中初始化(最小)的大小(字节)PGCMX：perm代的最大容量(字节)PGC：perm代当前新生成的容量(字节)S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比E：年轻代中Eden（伊甸园）已使用的占当前容量百分比O：old代已使用的占当前容量百分比P：perm代已使用的占当前容量百分比S0CMX：年轻代中第一个survivor（幸存区）的最大容量(字节)S1CMX：年轻代中第二个survivor（幸存区）的最大容量(字节)ECMX：年轻代中Eden（伊甸园）的最大容量(字节)DSS：当前需要survivor（幸存区）的容量(字节)（Eden区已满）TT：持有次数限制MTT：最大持有次数限制,40,2020/5/9,主要看FGC，值不能太大,41,2020/5/9,4.1JVM调优,对于jvm调优的主要目的是减少GC的频率和FullGC的次数，过多的GC和FullGC会占用很多的系统资源（主要是CPU）影响系统的吞吐量，特别要关注FullGC，因为它是对整个堆进行整理，导致FullGC的一般几种情况：,1.老年代空间不足2.调优时尽量让对象在新生代GC被回收，让新生代多存活一段时间和不要创建过大的对象以及数组避免直接在老年代创建对象3.增加持久代的空间4.垃圾回收机制不要手动触发(System.gc()，尽量依靠JVN的自身的回收机制,42,2020/5/9,调优过程主要是通过控制堆内存的各个部分的比例和GC的策略来实现，下面看一下各比例不良导致的一些情况：1.新生代设置过小一是新生代GC数非常频繁，增大系统消耗，二是导致大对象直接进入老年代，占据老年代的剩余空间，诱发FullGC2.新生代设置过大一是新生代设置过大会导致老年代过小(堆的大小是一定的)，从而诱发FullGC，二是新生代GC耗时大幅度增加，一般设置是-Xmn=-Xmx/3或者是-Xmn=-Xmx/4比较合适3.Survivor设置