主要学习四个方面的知识:
1.什么是性能测试
2.脚本调试
3.场景执行
4.性能诊断的分层思路
着重学习一些在书本上无法看到的技巧。
一.什么是性能测试
>究竟什么是性能测试?
1.性能测试是一种指标,表明软件或结构对于其及时性要求的符号程度;
2.性能是软件产品的一种特性,可以用时间来进行度量;
>ISO 9126质量模型中效率包含时间特性和资源特性;
模型中对时间要求遵循2.5.8原则。但是实际上我们看到的电商的响应,做到极致的可以达到几毫秒。
>对软件性能包含三个层面:
1.用户视角的软件性能;
2.管理员视角的软件性能;
3.开发视角的软件性能;
二.详细介绍
1.用户视角的软件性能
主要是响应时间,分为呈现时间和系统响应时间。
1.1呈现时间
是指例如我们打开一个网站的某一个网页,很快就能看到页面的这个时间,我们管其叫做呈现时间。
1.2系统响应时间
是指例如我们打开一个网站的某一个网页,将网页上的所有内容都加载完成,并且与后台服务交互全部完成之后的时间
1.3总结
综合1.1和1.2的概念分析我们可以看出来,呈现时间一般都会远远小于响应时间,所以我们在做性能测试的时候不要被一种假象所迷惑,即我们看到页面响应很快,但是实际压测时的响应时间很大,就认为压测结果有问题,一点要仔细分析出其本质。
2.管理员视角的软件性能
3.开发视角的软件性能(了解即可)
二.脚本调试
脚本调试的关键点是如下方面:
●事务定义
●思考时间
●关联
●脚本参数化
■时间(以保险为例:起保时间、终保时间)
■一次性数据。(注册卡号、身份证、车牌、捆绑数据ID)
2.1事务
2.1.1事务定义
就是记录各个操作步骤之间所用的时间。例如登陆功能,记录的就是点击登陆按钮到登录完成的时间;
事务定的很粗,时间不好界定,性能测试的时间指标就不准确;但是定的很细,脚本维护量会非常大。所以我们最好选择事务的方法是压测过程中看性能问题出在哪里?哪里有问题就要把这段的事务进行拆分。
2.1.2事务意义
再说一个场景,我压10并发,100并发,200并发,300并发,可以发现并发策略一般都是呈系数增加,加入我们压10并发此时响应时间为1秒,我们压20并发的时候响应时间突然变为了10秒,那么此时这个事务一定是性能的瓶颈点。
2.2思考时间(lr_think_time)
目的是为了真实模仿用户的操作行为。为什么这样说?假设一个用户打开一个网页,他会大致浏览一下网页的内容,在考虑下一步,在浏览的过程中它会有一定的等待时间,所以LR在录制脚本的时候在每一个事务的结束,会自动加上一定的思考时间。
2.3关联(最重要)
2.3.1应用场景
保险系统理赔:报案后会生成一个报案号,然后调度的时候会需要这个报案号。报案、调度这两个过程中会拿报案号作为一个关联(即拿上一个事务产生的出参来作为下一步操作的必备入参,实现一个数据传递的过程)。做性能测试时候,如果回放脚本不通,此时95%的比例是由于关联没有做好的原因,另外5%的比例有可能是参数化没有做好。
2.3.2左边界、右边界。最重要的是找到请求和响应。
2.3.3关联的意义:用你新生成的数据再去执行下一步的操作。
2.4脚本参数化
场景:20171201做的脚本,如果脚本中将时间写死为20171201,如果此时没有对其进行参数化设置,过一段时间必如在20171210去跑这个脚本,肯定是跑不通的。
2.4.1时间
实现方式:
(1)选择要参数化的时间,右键->Replace with a new parameter ,在弹出的选择框中,将Parameter type选择为Date/Time。
(2)点击Properties,弹出选择框,选择合适的时间格式。
其中Offect代表偏移量,如果你写了365days,那就意味着你的脚本下次执行的时间是在1年后。
2.4.2一次性数据
话题引出:生活中我们注册XX网站的会员,时常会使用自己的手机号,一个手机号被注册一次之后。肯定不会在允许重复注册。这个时候你的手机号就是一个一次性数据。此时我们就需要将其进行动态关联。目的是每次注册的时候都生成一个满足条件、新的手机号。
这里应该掌握新下参数化如何读取一个自己设定格式的文件(File)。
三.场景执行
这里要弄明白的事情有:
3.1并发策略
当我们想要并发200的时候,不是在同一个时间点全部压上去,而是要有一个压测的过程,比如我们可以设置为每2秒钟增加10个用户,这样的话我们的压力会在20秒内将200用户全部进行施压,结束的时候也应该设定为每秒钟退出几个用户,不是立刻就把200个用户全部停止。
3.2分机策略
当我们压测达到一定量,此时发现网络或者其他某一个指标已经非常高了,超出了我们压测机的能力,此时我们可以选择Controller-Load Generators来增加压测机。
四.性能诊断的分层思路(重点核心)
●性能监控和分析的原则
◆木桶原则
含义:系统由CPU、内存、硬盘组成,它们此时相当于木桶的每个板子,当你往这个木桶倒水的时候,哪块板子差,那它直接会制约木桶容纳水的能力的表现。反映在硬件上例如:当CPU已经达到100%了,而此时你的硬盘I/O读写还非常小。总结性来讲,这个木桶原则认为,你的一个被测试系统的性能应该是由一个指标所制约。
◆2/8原则
含义:认为影响性能的点可能集中在很小的功能上,把这部分小的部分进行改进,即会大幅度提高系统的性能。
◆让数据说话
含义:通过监控数据的前后变化来分析、说明系统性能,不能感性的通过盲目判断对系统性能乱下结论。
●监控思路
◆分层
含义:硬件、软件、数据库、代码、中间件;逐层去分析。
◆专业工具
中间件:比如Tomcat、Weblogic、数据库每一层都有开源、免费的工具。
◆优先级
1.具体该如何进行性能测试分析:
应用 | 哪个函数最耗时?执行了多少次? |
中间件 | 连接池、JVM、线程数是否合适? |
数据库 | 哪句SQL语句慢?哪个参数不对? |
操作系统 | 哪个系统参数不合适? |
主机 | CPU、内存是否是瓶颈? |
存储 | I/O利用率如何?存储空间是否够大? |
网络 | 带宽利用率如何? |
MySQL稳定性差,Oracle稳定性高。
用机器的数量弥补性能的缺失。
●分层
主要只的是以下几个方面:
•业务指标:TPS、响应时间、错误率。
•资源:CPU、内存、disk
•进程:top、vmstat
•系统调用或者应用监控
♦前端:图片大小等
♦中间件
♥线程、JVM、连接池。
♦数据库
♥AWR、ADDM
♥慢查询
1.一个误区
好多客户关注并发数多少,举个例子:同一个用户一秒钟点击一次,10秒钟点击一次,和10秒钟只点击一次,对系统的压力肯定是不同的,但是并发数确实是1.作为并发数不能作为性能测试的指标。
2.一个公式
并发数=响应时间*TPS
3.操作系统性能分析树
数据库查表主要就是对磁盘的查询。
其优先级为:内存>硬盘>CPU,因为CPU过高不一定就是CPU的问题,内存不够、磁盘不够会导致CPU不够。所以我们分析的时候要有优先顺序。
4.进程TOP
这里说的就是Windows进程管理器:
5.浏览器访问机制,发起http请求->http请求被服务端接收后会返回html,htm里面会嵌套着jsp、js、css等,动态加载的时候如果包含图片,是将图片从服务器进行下载,下载后在继续展示。
6.JVM代码加载。创建对象的时候会占用内存。
●Web前端性能优化常用方法
•减少http请求
•使用浏览器缓存
•启动压缩
尽量在本地解压缩。
•图片优化
•Css放在页面最前端、JS在页面下面
●中间件
•线程(阻塞)
一个线程只能调用一个CPU,当一个线程的服务过长时,CPU利用率会更高,此时有太多的CPU都没有作用。所以开发的东西一般要并行,不要串行。
•JVM
♦堆内存、栈内存
掌握一个监控工具:Java监视和管理控制台。
♦新生代(Young)、老年代(Old)、永久区(Permanent)
•连接池
♦当前连接数
♦最大连接数
并不是设定的越大越好。
♦平均连接数
•Css放在页面最前端、JS在页面下面
●ORACLE监控
•AWR
主要关注当前的TOP SQL,哪些耗CPU、哪些耗内存、哪些执行次数比较多。
•ADDM
•AWR-diff
•系统核心参数
♦IPC
♦进程
♦线程
♦文件
♦SWAP
♦绑定CPU绑卡