浅谈性能测试问题定位
什么是系统的性能?
当一个系统被开发出来后,功能均被实现了,系统进入稳定的运行状态。但系统的运行得怎么样,还是有待验证。系统的运行得怎么样即可以简单理解为系统的性能。
什么是系统的性能测试?
在指定的软件、硬件、网络条件下,通过编制脚本运行模拟多种环境进行测试(如:正常环境、峰值环境、负载环境等)对系统各项性能指标进行测试,从而发现系统的性能瓶颈。
简单来说,就通过测试策略,测定工具,模拟真实的用户使用环境验证系统运行得怎么样。
性能测试目的:并发、负载(最多容纳多数人)、稳定性(高负载的情况下是否稳定)、极限(拐点、压崩:故障转移是要压崩溃的)
性能测试准备
1. 性能测试对象及目标
测试对象可以归结为“业务功能”。测试前,需要了解我们需要测试的业务功能(不深入细节)有哪些,比如“购买商品”、“寄送快递”。
有没有必要测?需求来源哪里?,有没有数据支撑测试这个需求的必要性?
通常,可以从以下几个方面考虑:
1)是否核心功能,是否要求严格的质量
2)是否常用、高频使用的功能
3)可能占用系统较多资源的功能
4)使用人数多还是少
5)在线人数多还是少
拆分对象
先从业务上来分,实现这个完整的功能包含哪些流程、环节
举例:购买商品
登录->搜索商品->提交订单->支付订单->退出
指标分析
分析性能需求指标(如“支持300人并发登录”)是否合理
有必要测试这个需求,考虑需求指标是否合理?有没有数据支撑?
1)采样时间段内系统使用人数
2)采样时间段内系统在线人数
3)采样时间段内系统(页面)访问量
4)采样时间段内请求数
常用分析思路:
2/8法则
2/8法则:80%的业务量在20%的时间里完成。这里,业务量泛指访问量,请求数,数据量等
2. 服务器是什么系统
3. 服务器IP地址
4. 服务器和软件配置
5. 测试机配置(考虑是否需要分布式测试)
性能测试指标
1. 响应时间:
指的是从客户端发起请求开始,到客户端接收到从服务器端返回的响应结束,这个过程所耗费的时间,响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示:响应时间=网络响应时间+应用程序响应时间。一般为258原则,或1357原则:1s优秀,3s良好,5s及格,7s不合格。
2.平均响应时间:
所有请求花费的平均时间
3.90%的响应时间
90% 的请求响应时间都处在这个值以下
如:如果有100个请求,其中 98 个耗时为 1ms,其他两个为 100ms
平均响应时间: (98 * 1 + 2 * 100) / 100.0 = 2.98ms,但是,2.98ms并不能反映服务器的整体效率,因为98个请求耗时才1ms
在评估性能测试结果时,除了要考虑事务的平均响应时间,还要考虑90%的响应时间。
4. 吞吐量
吞吐量是我们常见的一个软件性能指标,对于软件系统来说,“吞”进去的是请求,“吐”出来的是结果,而吞吐量反映的就是软件系统的“饭量”,也就是系统的处理能力
简单来说,就是单位时间内处理请求的数量。
吞吐量越大,表示服务器的CPU处理请求的速度越快。
5. TPS
每秒钟系统能够处理事务或交易的数量,衡量系统处理能力的重要指标
TPS峰值是指在响应时间合理范围内TPS的最大值,一般取TPS峰值并发数的75%,持续1小时进行稳定测试
6.点击率
单位时间用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标:WEB应用是“请求-响应”模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位。
点击率越大,对服务器的压力越大。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求。
7 .思考时间
即请求间的停顿时间。实际中,用户在进行一个操作后往往会停顿然后再进行下一个操作,为了模拟这种用户行为而引入了该概念
而什么时候需要设置思考时间呢?
为了保证测试复合业务的时候,各个业务之间的比例关系符合我们的真实生产环境。
举例说明,比如一个论坛系统,每天最常处理的业务有两个:A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢,答案很明显,看帖子多,回复的少一些。假设A:B=2:1。
如果我们不设置考虑时间,对2路A的脚本,1路B的脚本进行性能测试
在跑AB脚本的时候,这两组脚本都在尽全力争夺服务器的资源,他们的并发路数虽然是2:1,但是给服务器的压力却不一定是2:1,可能会出现偏差,A查看帖子由于响应时间短,因此跑的次数更多,最后的比例可能是4:1
上面的例子,如果我们测出的结果是B回复帖子的吞吐量不够,响应时间太长,那可能是因为A业务抢走了过多的,本不属于A的资源,而引起了B的性能降低。
8.资源利用率
指的是对不同系统资源的使用程度,例如服务器的CPU(s),内存,网络带宽等。资源利用率通常以占用最大值的百分比n%来衡量。
**性能结果分析
1.压测结果指标**
Samples:表示一共发出的请求数
Average:平均响应时间,默认情况下是单个Request的平均响应时间(ms)
Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志,配合开发查找定位原因
Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力,tps越高说明服务器处理能力越好
聚合报告中的,吞吐量=完成的transaction数/完成这些transaction数所需要的时间;平均响应时间=所有响应时间的总和/完成的transaction数;失败率=失败的个数/transaction数总的来说,对于jmeter的结果分析,主要就是对jtl文件中原始数据的整理
2.压测结果分析
Error%:确认是否允许错误的发生或者错误率允许在多大的范围内;
Throughput:吞吐量每秒请求的数大于并发数,则可以慢慢的往上面增加;若在压测的机器性能很好的情况下,出现吞吐量小于并发数,说明并发数不能再增加了,可以慢慢的往下减,找到最佳的并发数;
压测结束,登陆相应的web服务器查看CPU等性能指标,进行数据的分析;
最大的tps:不断的增加并发数,加到tps达到一定值开始出现下降,那么那个值就是最大的tps。
最大的并发数:最大的并发数和最大的tps是不同的概率,一般不断增加并发数,达到一个值后,服务器出现请求超时,则可认为该值为最大的并发数。
压测过程出现性能瓶颈,若压力机任务管理器查看到的cpu、网络和cpu都正常,未达到90%以上,则可以说明服务器有问题,压力机没有问题。
影响性能考虑点包括:数据库、应用程序、中间件(tomact、Nginx)、网络和操作系统等方面。
3.性能测试关注点
1.客户端响应时间是否满足要求
2.服务器资源使用情况是否合理
3.应用服务器和数据库资源使用是否合理
4.最大访问数,最大业务处理量是多少
5.系统可能存在的瓶颈在哪里
6.能否支持7*24小时的业务访问
7.架构和数据库设计是否合理
8.内存和现成资源是否可以被正常回收
9.如果系统出现不稳定情况,其可恢复性如何
1.CPU、TPS存在明显波动则存在瓶颈
2.并发时服务日志级别需调整为error级别
3.通常请求由一个线程负责执行,占用一个逻辑CPU
4.若并发量增加而CPU使用率未增加则存在瓶颈
5.CPU负荷集中在应用服务器和数据库服务器上
6.内存负荷集中在应用服务器和数据库服务器上
7.磁盘负荷集中在数据库/文件服务器上
8.对外网络流量集中在负荷均衡器(nginx、LVS)上