性能测试工具 对于新手性能测试该如何切入

周小丽 · June 01, 2017 · Last by 123 replied at February 13, 2019 · 1741 hits

前些日子在testerhome群问了不少关于LR性能测试的问题,现在总结归纳下。在此感谢一些东哥等人的指点,虽然被说的体无完肤😁 .

一、 业务类型选取

1、 针对应用服务器的压测,可根据业务配比选择交易较高的业务
2、 针对数据库服务器的压测,可选择对数据库进行增删改查频率较高的业务

二、 业务数据分析

1、 需要调研每个关键接口每天调用的次数,这样可以算出单笔业务的TPS
比如:系统每天订单提交量为1000(基本每人一单),根据2/8定律,80%的交易在20%的时间完成,每天交易量1000笔,一天8小时
TPS=80%*1000/(8*3600*20%)=0.139
并发数 / (响应时间+考虑时间) ≈ 总业务数 /总时间 = TPS
假如用户对响应时间的上限为2秒
并发数 ≈ 2*0.139 = 0.278
2、 需要调研访问系统的用户数及登录时长,算出系统的并发用户数
比如:某系统有30000个用户,平均每天大约有1000个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
计算平均的并发用户数: C = nL/T
C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度
C = 1000*4/8 = 500

三、 脚本录制方式选择

1、 如果应用是WEB应用,首选是HTML-based方式;
2、 如果应用是使用HTTP协议的非WEB应用,首选是URL-based方式;
3、 如果WEB应用中使用了java applet程序,且applet程序与服务器之间存在通讯,选用URL-based方式;
4、 如果WEB应用中使用的javascript、vbscript脚本与服务器之间存在通讯(调用了服务端组件),选用URL-based方式。

四、 模型创建

例如:100次业务中,有20次购买,另外80次只浏览不购买,购买前都需要浏览商品
1、 业务模型
浏览商品—> 购买—> 80%
浏览商品— — —> 20%
2、 接口模型
浏览商品— — —> 100/120
购买 — — — —> 20/120

五、 通用的测试策略

1、 基准测试
在系统没有压力的情况下对各功能进行单线程的测试,测试结果主要用来作为基准值为后续测试结果做比对参数
2、 单交易测试
采用梯度测试方法对单个功能或接口在不同压力下的进行测试,可以得出单个功能的最大TPS,结合基准测试的结果可以分析性能的增长趋势(响应时间/系统资源等增长趋势)
3、 混合场景测试
使用相关模型进行测试的场景,主要验证整体性能是否满足上线要求,或者给出基于模型的最大TPS
4、 稳定性测试
一般在系统最大TPS的 80% 压力下 执行 12或24小时,主要验证系统在执行大量业务交易(一般模拟一个月的业务量)后性能表现

六、 场景分析

来源:http://www.cnblogs.com/stay-sober/p/4136062.html

⑵.事务摘要

现象:
Transaction Summary 部分显示:
- Average表明事务的平均响应时间。响应最慢的事务:check_itinerary;
- Fail表示事务失败的个数。失败较多的事务:check_itinerary;
- Std. Deviation表明事务的波动情况、稳定性。波动较大的事务:check_itinerary;
- 90 Percent表明90%的事务的响应时间,波动大的事务查看90%的响应时间较准确。90%响应时间较大的事务:check_itinerary;
分析:
从响应时间、波动性、失败情况可以看出问题最突出是check_itinerary事务,进一步分析该事务。

⑵.Running Vusers

running vuser为场景运行时,正在运行的vuser情况。由于性能的问题由并发增大引起,所以,看其他指标需要结合running vuser情况。

现象:
起始为10个vuser,以10的阶梯递增,在1:36秒维持了3分钟,而后以1个阶梯减少;
分析:
需结合其他指标图表。

⑶.Errors per Second (by Description)

每秒的错误数信息。可以查看随着运行时间,不同错误的发生曲线。

现象:
在高并发时,前三个为突出的问题;Error 27728、27727出现在高并发阶段;Error 17999 运行1分开始小幅波动,但具体什么错误不知道。

  • Error 27796:connection refused;
  • Error 26377:未找到关联;
  • Error 26374:响应为空,可能导致了未找到关联的错误;
  • Error 17999:message box处发生的错误;
  • Error 27728:step download timeout下载non-resource元素时,下载超时;
  • Error 27727:step download timeout下载resource元素时,下载超时; 前3个问题发生较多,中间有下降、上升的大幅波动,最后下降,呈M状,3个问题的趋势一致。 分析:
  • Error 27796:说明了和服务端连接有问题;需要确定连接数是不是满了,排查连接各环节的连接设置,看Connections图;
  • Error 26377、26374:说明了,服务端未响应;进而需要看throughput、Average Transaction Response Time、transactions per second此类服务端性能的指标;
  • Error 17999:暂不清楚;
  • Error 27728 、27727:在高并发时才出现的下载超时的问题,应考虑服务端的处理能力;(如果场景开始就有下载超时,就需要检查runtime setting-internet protocol中对超时时间的设置是不是太小了) 结合vuser图,错误集中时段是并发数高于55个vuser 时间段,高并发导致了大量的error。系统目前性能情况,最大允许并发为55。

Error:连接拒绝
I.1 Hits per Second-Connections

连接数显示了场景运行时,打开的http连接数。
根据上一步的推论,查看随着vuser的增加,请求的增加,连接数是否达到了最大,因此导致了服务端拒绝访问的问题。如果是这样的情况则需要调整web服务端的最大连接数。
正常情况下,连接数的趋势应该随着vuser增加,请求增加,是逐步增加。但是此图曲线有中间的下降,需要结合点击率来较为准确的查看请求情况。

现象:
点击率开始为增加趋势,中间有降、升,而后波动,最后下降,基本呈M状。
分析:
考虑到连接统计的延迟,连接数基本符合点击率的波动情况,但是后面仍然保持在较高的连接数;
推论一、是否是因为连接未及时关闭,致使连接数满了,继而导致了服务端拒绝连接的问题;进而需要查看每秒的连接打开和关闭情况。
推论二、服务端、客户端之间的连接数设置的过小,导致连接数满了。

I.2 Connections per Second

显示了在运行时,打开和关闭的http连接情况。如果连接关闭的曲线和连接打开的曲线差得多,表明连接未被及时关闭,连接被占用,会导致服务端连接的满了,拒绝客户端的访问的错误。

现象:
曲线基本一致。
分析:
不是因为连接关闭不及时导致的连接数满,服务端拒绝访问的问题。所以根据上一步的推论二基本确定连接数设置问题,需要进一步查看web server、服务端操作系统连接数设置、客户端操作系统连接设置、lr运行的设置等相关的连接数情况。
Error:服务端响应不过来

II. 1 Throughput
显示场景运行时,每秒从服务端获得的数据量,可以判断服务器的处理能力。

现象:
吞吐量开始递增,而后在高并发阶段趋势较平稳,最后下降。
分析:
服务端处理能力较为稳定,没有发现问题。

II. 2 Hits per Second - Average Transaction Response Time

Average Transaction Response Time显示场景运行时,事务执行所用的时间。事务的响应时间和请求数结合来看,查看check_itinerary事务响应时间。

现象:
两个曲线在中间大幅下降后,后面波动的趋势大致相符。
分析:
响应时间的降低是因为点击率减少,服务端接收到的实际请求减少,压力较小,响应快了。未分析出其他问题。

II. 3 Transaction per Second

显示了事务的成功、失败、停止的数量,通过此项可以确定系统在时间点的事务负载情况。和平均事务响应时间对比,可分析事务数对执行时间的影响。

现象:
check_itinerary成功的事务较波动,数值较小;check_itinerary失败的事务集中时间为并发高峰时段。
分析:
TPS数值太小,说明了的服务端处理事务能力较弱,继而需要查看system resource图。

II. 4 System Resource
** 处理器的指标**

现象:
Processor_total大部分在90%以上,表明cpu配置较低;
Interrupted/sec中断并发高时较多,但低于60%;
Process_xiwin32较为平稳;推测为xiwin32进程(web server);
Processor queue length cpu的平均负载很大;
分析:
系统cpu瓶颈较明显,又考虑process_xiwin32占用cpu不算多。推测是由于系统服务端其他进程占中了大部分cpu。优化服务端的进程情况,使web服务更有效的占用cpu;或更换高配的cpu;或改为linux服务器,减少其他进程的占用。

** 内存的指标**

现象:
Private byte 随并发请求增加,内存相应增加,后面下降。
分析:
未发现问题。

磁盘的指标

现象:
随着并发请求增加,磁盘交互响应增加,比较平稳;
分析:
未发现问题;
Transaction:check_itinerary

III.1 Web Page Diagnostics
此图为对事务的各元素各种响应环节的细分情况。以下图为check_itinerary的事务细分情况。

现象:
check_itinerary事务中itinerary.pl和sh_itinerary.gif的下载时间最长,请求itinerary.pl响应字节数较大,接收时间较长;sh_itinerary.gif并不大,但是first buffer time很长。
分析:
请求itinerary.pl的业务为查询日程安排,推论是因为响应的数据量较大,导致的接收时间长。可以考虑优化该文件的代码,拆分文件,压缩输出等。
sh_itinerary.gif文件 first buffer time较长,进而分析该项的time to first buffer情况。
First buffer time:
细分为服务端时间、网络时间。

现象:
网络时间明显很大。
分析:
此文件的网络时间较长,可推论出网络方面的问题,需要进一步查看网络指标确定。

七、 瓶颈查找定位

查找瓶颈时按以下顺序,由易到难。
---〉服务器硬件瓶颈
---〉网络瓶颈(对局域网,可以不考虑)
---〉服务器操作系统瓶颈(参数配置)
---〉中间件瓶颈(参数配置,数据库,web服务器等)
---〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)

共收到 2 条回复 时间 点赞
Author only
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up