1 性能测试目的
性能测试的目的：验证软件系统是否可以达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件。linux
最后起到优化系统的目的性能测试包括以下几个方面：web
1.评估系统的能力:测试中获得的负荷和响应时长数据能够被用于验证所计划的模型的能力，并帮助作出决策正则表达式
2.识别体系中的弱点：受控的负荷能够被增长到一个极端的水平并突破它，从而修复体系的瓶颈或薄弱的地方数据库
3.系统调优:重复运行测试，验证调整系统的活动是否获得了预期的结果，从而改进性能数组
检测软件中的问题:长时间的测试执行可致使程序发生因为内存泄漏引发的失败，揭示程序中隐含的问题或冲突缓存
4.验证稳定性(Resilience)、可靠性（Reliability）:在一个生产负荷下执行测试-必定的时间是评估系统稳定性和可靠性是否知足要求的惟一方法服务器
2 性能测试常见分类
性能测试包括负载测试、强度测试、容量测试等网络
2.1负载测试（Load Testing）
负载测试是指经过测试系统在资源超负荷状况下的表现，来发现设计上的错误或验证系统的负载能力。架构
负载测试的目标是肯定并确保系统在超出最大预期工做量的状况下仍能正常运行负载测试还要评估性能特征，如响应时长、事务处理速率并发
2.2强度测试（Stress Testing）：压力测试
压力测试对系统不断施加压力的测试，是经过肯定一个系统的瓶颈或者不能接收的性能点，来得到系统能提供的最大服务级别的测试。
好比测试一个web站点在大量负荷下，什么时候系统的响应会退化或失败。
2.3容量测试(Volume Testing)
容量测试肯定系统可处理同时在线的最大用户数
针对上述 负载测试、压力测试、容量测试 举个例子
例：一我的背X斤
负载测试：200斤状况下，是否能坚持5分钟
压力测试：200,300,400... 斤状况下，他的表现，何时失败，失败以后什么表现，从新扛200是否正常
容量测试：在坚持5分钟的状况下，他一次最多能扛多少斤
3 性能测试的常见指标
常见的两种架构进行软件测试：B/S、C/S
3.1 B/S架构-常见性能指标
对于B/S架构的软件，通常会关注以下Web服务器性能指标
| 概念 |
说明 |
| Avg Rps |
平均每秒钟的响应次数=总请求次数/秒数 |
| Avg time to last byte per terstion(mstes) |
平均每秒业务脚本的迭代次数 |
| Successful Rounds |
成功的请求 |
| Failed Rounds |
失败的请求 |
| Successful Hits |
成功的点击次数 |
| Failed Hits |
失败的点击次数 |
| Hits Per Second |
每秒点击次数 |
| Successful Hits Per Second |
每秒成功的点击次数 |
| Failed Hits Per Second |
每秒失败的点击次数 |
| Attempted Connections |
尝试链接数 |
| Throughput |
吞吐率 |
3.2 C/S架构-常见性能指标
对于C/S架构的程序，因为软件后台一般为数据库，因此咱们更注重数据库的测试指标。
除了表格里面的概念，还有部分指标：CPU占用率、内存占用率、数据库链接池等
| 概念 |
说明 |
| User Connections |
用户链接数，也就是数据库的链接数量 |
| Number of Deadlocks |
数据库死锁 |
| Butter Cache Hit |
数据库Cache的命中状况 |
4 性能测试结果分析
4.1如何分析性能测试结果
- 分析在整个性能测试执行期间，测试环境是否稳定正常。
例如，测试期间运行Jmeter的及其CPU占用率常常达到100%（或内存占用很高）、测试网络出现拥塞致使响应延迟、待测系统参数配置错误（JDBC链接池等）.....
2. 检查jmeter测试脚本参数设置是否合理、检查jmeter运行模式是否合理。
例如，线程组的参数Ramp-Up Period(in seconds)设置为0或1，jmeter就会瞬间启动该线程组下的全部虚拟用户，会为待测服务器形成巨大的压力，轻则致使服务器响应时长超长，重则致使部分虚拟用户等待响应超时而报错。
3. 检查测试结果是否暴露出了系统瓶颈。
性能测试分析的原则：由表及里、由内而外、抽丝剥茧
响应时长，主要包括2部分：服务器响应时长(应用服务器、数据库服务器的响应时长)、网络响应时长。
4.2如何借助监听器发现性能缺陷
4.2.1图形结果(Graph Results)
| 概念 |
说明 |
| 样本数目 |
总共发送到服务器的请求数 |
| 最新样本（黑色） |
表明时间的数字,是服务器响应最后一个请求的时间(当前采样响应时长) |
| 吞吐量(绿色) |
服务器每分钟处理的实际请求数 |
| 平均值(蓝色) |
总运行时间除以发送到服务器的请求数（平均采样响应时长） |
| 中间值（紫色） |
表明时间的数字，有一半的服务器响应时间低于该值而另外一半高于该值 |
| 偏离(红色) |
服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布 |
测试人员能够经过增长并发线程数或减小脚本中的延迟，来找到系统支持的最大吞吐率。
图形结果中比较有参考价值的字段是：平均值、偏离、吞吐量。
4.2.1.1平均值
随着并发压力的加大，以及时间延长，系统性能所发生的变化。正常状况下，平均采样响应时长曲线应该是平滑的，并大体平行于图形下边界。
可能存在性能问题的平均值：
①平均值在初始阶段跳升，然后逐渐平稳起来。
一是系统在初始阶段存在性能缺陷，须要进一步优化，如数据库查询缓慢
二是系统有缓存机制，而性能测试数据在测试期间没有变化，如此一来一样的数据在初始阶段的响应时长确定较慢；这属于性能测试数据准备的问题，不是性能缺陷，需调整后在测试
三是系统架构设计致使的固有现象，例如在系统接收到第一个请求后，才去创建应用服务器到数据库的连接，后续一段时间内不会释放链接。
②平均值持续增大，图片变得愈来愈陡峭
一是可能存在内存泄漏，此时能够经过监控系统日志、监控应用服务器状态等常见方法，来定位问题。
③平均值在性能测试期间，忽然发生跳变，而后又恢复正常
一是可能存在系统性能缺陷
二是可能因为测试环境不稳定所形成的（检查应用服务器状态【CPU占用、内存占用】或者检查测试环境网络是否存在拥塞）
4.2.1.2偏离
观察采样响应时长标准差，能够判断数据的分布是否均匀。理想状态是平滑的。
4.2.1.3 吞吐量
服务器每分钟处理的实际采样数。首先经过增长并发线程数或减小脚本中的延迟，来找到系统支持的最大吞吐率。而后将系统实际支持的最大吞吐率和预期吞吐率进行比较，以便确认系统表现是否知足用户需求。
4.2.2断言结果(Assertion Results)
断言结果试图会展现每一个采样携带的标签，若是断言有问题，会进行显示。
4.2.3查看结果树(View Results Tree)
查看结果树会以树的方式来展现全部采样响应结果，测试人员能够经过它来查看任何采样的响应。
查看结果数通常用于调试性能测试脚本。还能够经过查询结果，利用正则表达式，从响应结果中提取数据。
4.2.4用表格查看结果
为每个采样结果建立一行，可是会占用较多内存。
在“用表格查看结果”中，测试人员能够看到采样时间、系统响应时长、字节数等，且能够肯定问题采样发生的准确时刻。
4.2.5聚合报告（Aggreate Report）
部分概念以下：
| 概念 |
说明 |
| Label |
说明是请求类型，如Http，FTP等请求 |
| #Samples |
也就是图形报表中的样本数目，总共发送到服务器的样本数目 |
| Average |
也就是图形报表中的平均值，是总运行时间除以发送到服务器的请求数（平均响应时间） |
| Median |
也就是图形报表中的中间值，是表明时间的数字，有一半的服务器响应时间低于该值而另外一半高于该值 |
| 90%line |
是指90%请求的响应时间比所得数值还要小 |
| Min |
是表明时间的数字,是服务器响应的最短期 |
| Max |
是表明时间的数字,是服务器响应的最长时间 |
| Error% |
请求的错误百分比 |
| Throughput |
也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟 |
| KB/sec |
是每秒钟请求的字节数（数据传输量） |
| Throughput |
也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟 |
聚合报告综合判断系统性能是否知足要求。比较关心的几个统计值，包括平均响应时长、90%阈值、吞吐率（每秒完成请求数）、错误率。
PS:90%line的定义：
一组数由小到大进行排列，找到他的第90%个数（假如是12），那么这个数组中有90%的数将小于等于12 。
用在性能测试的响应时间也将很是有意义，也就是90%请求响应时间不会超过12 秒。
4.2.6聚合图形(Aggregate graph)
聚合图形与聚合报告一致，区别在于聚合图形有生成的图表。
4.2.7概要报告(summary report)
| 概念 |
说明 |
| Label |
采样标签 |
| #Samples |
标签名相同的总采样数 |
| Average |
请求(事务)的平均响应时间 |
| Min |
标签名相同的采样中，最小的响应时长 |
| Max |
标签名相同的采样中，最大的响应时长 |
| Std.Dev. |
采样响应时长的标准差 |
| Error% |
事务发生错误的比率 |
| Throughput |
该吞吐率以每秒/分钟/小时发生的采样数来衡量（TPS） |
| KB/sec |
吞吐量以每秒KB来衡量（即每秒数据包流量） |
| Avg.Bytes |
以字节为单位的采样响应平均大小(平均数据流量) |
4.2.8服务器性能监控设置
JMeter使用plugins插件进行服务器性能监控，对服务器的 CPU、内存、Swap、磁盘 I/O、网络 I/O 进行监控。客户端添加CPU监控Permon Metrics Collector，服务器端开启代理，在HTTP请求的时候，就能进行服务器资源的监控状况。
4.2.8.1服务器插件下载
访问网址https://jmeter-plugins.org/downloads/old/，下载三个文件。其中客户端插件JMeterPlugins-Standard和JMeterPlugins-Extras(目前我使用的版本是1.4.0)，
访问网址https://jmeter-plugins.org/wiki/Start/，下载服务器端插件ServerAgent的。
4.2.8.2插件客户端配置
解压客户端的两个文件，进入其路径JMeterPlugins-Extras(Standard)-1.3.1\lib\ext，复制JmeterPlugins-Extras.jar(JmeterPlugins-Standard.jar)两个文件，放到JMeter客户端的lib/ext文件夹中,打开JMeter，可在监听器中看到Permon Metrics Collector，客户端配置成功。
4.2.8.3插件服务器端配置
将ServerAgent-2.2.1.jar上传到被测服务器，解压，进入目录，Windows环境，双击ServerAgent.bat启动；linux环境执ServerAgent.sh启动，默认使用4444端口，出现以下状况
即服务端配置成功。
11-4.Permon Metrics Collector监控的执行