Loadrunner分析结果图说明.doc
《Loadrunner分析结果图说明.doc》由会员分享，可在线阅读，更多相关《Loadrunner分析结果图说明.doc（5页珍藏版）》请在冰点文库上搜索。
Loadrunner分析结果图说明
1、RunningVusers图
使用Vuser图可以确定方案，执行期间Vuser的整体行为。
X轴表示从方案开始运行以来已用的时间。
Y轴表示方案中的Vuser数。
Vuser-Rendezvous图主要反映Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.
图中可以看到在1分4秒的地方50个用户全部集中到达集合点，持续了5分48秒开始释放用户，整个过程持续了6分钟。
2、HitsperSecond图
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
3、Throughput图
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。
其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
X轴表示从方案开始运行以来已用的时间。
Y轴表示服务器的吞吐量（以字节为单位）。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。
4、TransactionSummary图
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
5、AverageTransactionResponseTime图
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：
随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
可以将事务平均响应时间图与“正在运行的Vuser”图进行比较，了解正在运行的Vuser的数目对事务执行时间产生的影响。
例如：
如果平均事务响应时间图显示执行时间逐渐改善，则可以将其与“正在运行的Vuser”图进行对比，看执行时间是否因为Vuser负载减少而得到改善。
如果定义了可以接受的最小和最大事务性能时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
TransactionResponseTime—percentile（事务响应时间的百分比图）
用于分析在给定时间内执行的事务百分数，有助于确定满足了所定义的性能标准的事务的百分比，最大反应时间可能非常的长，但如果大多数定义的事务访问时间可以接受，系统总体也就满足了需求。
X轴代表在总事务数所占百分比，Y轴代表执行事务消耗的时间。
Transactionpesponsetime—summay（事务响应时间摘要）
6、WindowsResources图
X轴表示已用时间。
Y轴表示资源使用率。
如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Availablebytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率（highpageoutrate）；进程进入不活动状态;
交换区所有磁盘的活动次数可高；可高的全局系统CPU利用率;
内存不够出错（outofmemoryerrors）
如果System\ProcessorQueueLength大于2，而处理器利用率（ProcessorTime）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间（slowresponsetime）；CPU空闲时间为零（zeropercentidleCPU）
过高的用户占用CPU时间（highpercentuserCPU）；过高的系统占用CPU时间（highpercentsystemCPU）
长时间的有很长的运行进程队列（largerunqueuesizesustainedovertime）
最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
如果出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。
否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
录制脚本中关于验证码的问题？
关于集合点：
插入集合点是为了衡量在加重负载的情况下服务器的性能情况。
譬如：
在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，从而达到测试计划中的需求。
注意：
集合点经常和事务结合起来使用。
集合点只能插入到Action部分，vuser_init和vuser_end中不能插入集合点。
关于事务：
事务（Transaction）：
为了衡量服务器的性能，我们需要定义事务。
比如：
我们在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，我们把这个操作定义为一个事务，这样在运行测试脚本时，LoadRunner运行到该事务的开始点时，LoadRunner就会开始计时，直到运行到该事务的结束点，计时结束。
这个事务的运行时间在结果中会有反映。
插入事务操作可以在录制过程中进行，也可以在录制结束后进行。
LoadRunner运行在脚本中插入不限数量的事务。
注意：
事务的名称最好要有意义，能够清楚的说明该事务完成的动作。
升级会员 