主要学习四个方面的知识：
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绑卡