标签：采样 && 4.2 性能 响应 测试 服务器 jmeter

1 性能测试目的

性能测试的目的：验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件。

最后起到优化系统的目的性能测试包括如下几个方面：

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如何分析性能测试结果

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监控的执行

 

标签：采样,&&,4.2,性能,响应,测试,服务器,jmeter
来源： https://www.cnblogs.com/wendyw/p/11626915.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。