Loadrunner进阶指南
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
3.9事务
3.9.1响应时间
事务是指用户在客户端做一种或多种业务所需要的操作集,通过事务函数可以标记完成该业务所需要的操作内容;另一方面事务可以用来统计用户操作的响应时间,事务响应时间是通过记录用户请求的开始时间和服务器返回内容到客户时间的差值来计算用户操作响应时间的,如图3.159
所示。
图3.159事务响应时间计算方式这里的响应时间不包含客户端
GUI 时间(例如浏览器解释页面所消耗的
时间)。
前面说响应时间是服务器返回和用户请求发出之间的时间差,那么得到这个时间就够了吗?
例如:现在有一场跑步比赛。当比赛完成后,可以得到每位运动员跑完整个比赛所需要消耗的时间,现在需要分析谁的起跑好、谁的冲刺好,能分析出来吗?答案是不能,虽然得到了最重要的完成比赛的响应时间,但是这对分析和优化几乎没有作用,因为只知道了结果而不知道过程。跑步的时间是由起跑、中途、冲刺等时间组成的,如果想要进行分析优化,必须先了解各个阶段所花费的时间和速度以及各个运动员的优缺点。
对于软件来说,通过事务得到的系统响应时间也是由非常多的部分组成的,一般来说响应时间由网络时间、服务器处理时间、网络延迟三大部分组成。先来看看当一个客户端发出请求到服务器返回需要经历哪些路径,如图3.160所示。
图3.160事务响应时间组成
1.网络时间
客户端发出请求首先通过网络来到Web Server 上(消耗时间为N1);然后Web Server 将处理后的请求发送给App Server (消耗时间为N2);App Server 将操作数据指令发送给Database (消耗时间为N3);Database 服务器将查询结果数据发送回App Server (消耗时间为N4);App Server 将处理后的页面发给Web Server (消耗时间为N5);最后Web Server 将HTML 转发到客户端(消耗时间为N6)。这里的N x 都是网络传输上的时间开销,没有计算业务处理所需要花费的时间。
2.服务器处理时间
另外一个方面还要考虑各个服务器处理所需要的时间WT 、AT 、DT 。
3.网络延迟
除了上面两种时间开销以外,还要考虑网络延迟的问
题。
所以最终的响应时间组成为:响应时间=网络延迟时间+WT+AT+DT +
(N1+N2+N3)+(N4+N5+N6)+WT+AT+DT 也可以简单认为响应时间由网络开销(前端)和服务
器端开销(后端)两大部分组成,如图3.161所示。那么这些消耗的时间都花在什么事情上了呢?影响网络的因素一般包括以下内容:1.前端Network
•DNS Lookup
•Time to connect
•Time to first buffer
•Network Time
•Download Time
•SSL handshake
•FTP authentication
•Client
Time
图3161事务响应时间组成详解
•Error Time
•网络延迟
2.后端服务
•Web Server
Servlet Time
Method Time
静态动态压缩
•App Server
EJB Time
Method Time
JNDI Lookup
•Database Server
JDBC Time
Connect Time
Execute Time
这里会发现响应时间的组成是非常复杂的,当性能问题出现时,想要定位到具体的代码级别是相当困难的。
3.9.2添加事务
通过事务监控响应时间,需要做的就是在请求的发出前添加一个事务开始的计数器,在请求结束的地方添加一个事务结束的计数器,VuGen会自动计算函数间的时间差。
通过工具栏上的事务按钮即可完成事务的添加操作,在请求之前单击插入事务开始按钮,如图3.162所示。
在弹出对话框中填写事务名称mainpage,如图3.163所示。
图3.162插入事务开始按钮图3.163设置事务名称
单击OK按钮后,可以得到事务开始的函数:
lr_start_transaction("mainpage");
通过这条语句开始了一个叫做mainpage的事务,然后在请求后添加一个事务结束函数,单击插入事务结束按钮,如图3.164所示。
这里提供了几个选项,选择LR_AUTO由VuGen自动判断状态,如图3.165所示。
图3.164插入事务结束按钮图3.165设置事务状态判断为LR_AUTO 这样就生成了一个事务结束的函数:
lr_end_transaction("mainpage",LR_AUTO);
这里事务的开始和结束名称需要配对。
事务设置结束,通过这两个函数完成了对事务的设计,运行脚本来看看效果。脚本如下所示:
Action()
{
lr_start_transaction("mainpage");
web_url("51testing","URL= ",LAST);
lr_end_transaction("mainpage",LR_AUTO);
return0;
}
在日志中可以看到以下信息:
Action.c(3):Notify:Transaction"mainpage"started.
//请求发送返回的相关日志
Action.c(5):Notify:Transaction"mainpage"ended with"Pass"status (Duration: 5.9749).
事务结束的说明中包含了请求所花费的时间为Duration=5.9749秒和事务结束的状态。通过事务可以获得每个操作所消耗的准确时间,例如查询、登录、删除操作。但是对于性能分析来说,这个时间还是太大了,无法有效地帮助我们定位性能瓶颈,LoadRunner能解决这个问题吗?抱歉,LoadRunner只能对自己发出的请求和服务器返回的内容进行网络级别的分析,也就是说LoadRunner能够分析的时间为客户到WWW服务器的时间N1和WWW服务器返回到客户的时间N6。这些时间主要和网络速度有关,可以用一个LoadRunner的名称来解释,叫做Web Page Breakdown,相关的具体分析可以参考第5.3.5节。
也就是说VuGen可以分析的时间只有客户端到Web Server之间的部分,后面从Web Server到App Server再到Database Server的时间只能得到一个总和。