首页 > 代码库 > lr测试结果分析

lr测试结果分析

 

 

      根据业务的运行情况入手,以突出问题为主线,定位瓶颈,进行调优;执行后再验证性能,未达到性能需求继续找突出问题,分步调优。本分析以error为主线,找error的产生原因,定位到了瓶颈,针对瓶颈做调优。性能分析包含系统架构的各方面、各环节。

 

⑴.Analysis Summary

场景的大概情况。

 

现象

     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较长,进而分析该项的timeto first buffer情况。

First buffer time

细分为服务端时间、网络时间。

 

现象:

     网络时间明显很大。

分析

     此文件的网络时间较长,可推论出网络方面的问题,需要进一步查看网络指标确定。

复制去Google翻译翻译结果
 

lr测试结果分析