LoadRunner测试SQL语句性能
发布: 20xx-9-13 17:28 | 作者: 网络转载 | 来源: 网络转载 | 查看: 274次
字号: 小 中 大 | 推荐给好友
本次通过loadRunner录制SQL Server介绍一下如何测试一个sql语句或存储过程的执行性能。
主要分如下几个步骤完成：
第一步、测试准备
第二步、配置ODBC数据源
第三步、录制SQL语句在Sql Server查询分析器中的运行过程
第四步、优化录制脚本，设置事务
第五步、改变查询数量级查看SQL语句的性能
第六步、在controller中运行脚本
下面开始具体的介绍：
测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装SQL SERVER数据库服务端及客户端，也可以确定一台装好的SQL SERVER服务器。 接下来，准备测试数据：对数据库测试时我们要考虑的不是SQL语句是否能够正确执行，而是在某数量级的情况下SQL语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某SQL语句的执行效率。 在查询分析器中运行如下脚本：
--创建测试数据库
create database loadrunner_test;
use loadrunner_test
--创建测试数据表
create table test_table
(username varchar(50),sex int,age int,address varchar(100),post int) --通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了 declare @i int
set @i=0
while @i<1000 //循环1000次，可以根据测试数据情况改变插入条数 begin
BEGIN TRAN T1
insert into test_table (username,sex,age,address,post) values ('户瑞海'+cast(@i as varchar),@i-1,@i+1,'北京市和平里'+cast(@i as varchar)+'号',123456);
IF @@ERROR <> 0
begin
rollback;
select @@error
end
else
begin
commit;
set @i = @i+1
end
end
好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置ODBC数据源，为了能让loadrunner能够通过ODBC协议连接到我们建立的SQL SERVER数据路，我们需要在本机上建立ODBC数据源，建立方法如下：
控制面板—性能和维护—管理工具—数据源（ODBC）--添加，在列表中选择SQL SERVER点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成ODBC的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。
配置好ODBC数据源后就要录制SQL语句在查询分析器中的执行过程了：
1、 打开loadrunner，选择ODBC协议
2、 在start recording中的application type 选择win32 application；program to record中录入SQL SERVER查询分析器的路径“..\安装目录\isqlw.exe”
3、 开始录制，首先通过查询分析器登录SQL SERVER，在打开的查询分析器窗口中输入要测试的SQL语句，如“select * from test_table;”
4、 在查询分析器中执行该语句，执行完成后，结束录制
好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我QQ，我把脚本发给你们），通过这些语句，我们
可以看出，登录数据库的过程、执行SQL语句的过程。
接下来，我们来优化脚本，我们分别为数据库登录部分和执行SQL语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下： Action()
{ double trans_time; //定义一个double型变量用来保存事务执行时间 lr_start_transaction("sqserver_login"); //设置登录事务的开始
lrd_init(&InitInfo, DBTypeVersion); //初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）
lrd_open_context(&Ctx1, LRD_DBTYPE_ODBC, 0, 0, 0);
lrd_db_option(Ctx1, OT_ODBC_OV_ODBC3, 0, 0);
lrd_alloc_connection(&Con1, LRD_DBTYPE_ODBC, Ctx1, 0 /*Unused*/, 0);
………………
trans_time=lr_get_transaction_duration( "sqserver_login" ); //获得登录数据库的时间
lr_output_message("sqserver_login事务耗时 %f 秒", trans_time); //输出该时间
lr_end_transaction("sqserver_login", LR_AUTO); //结束登录事务 lr_start_transaction("start_select");//开始查询事务
lrd_cancel(0, Csr2, 0 /*Unused*/, 0);
lrd_stmt(Csr2, "select * from test_table;\r\n", -1, 1, 0 /*None*/, 0);//此句为执行的SQL
lrd_bind_cols(Csr2, BCInfo_D42, 0);
lrd_fetch(Csr2, -10, 1, 0, PrintRow24, 0);
……………..
trans_time=lr_get_transaction_duration( "start_select" ); //获得该SQL的执行时间
lr_output_message("start_select事务耗时 %f 秒", trans_time); //输出该时间 lr_end_transaction("start_select", LR_AUTO); //结束查询事务
优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。
接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有Mercury 授权的SQL SERVER用户license，在运行该脚本时回报错，提示“You do not have a license for this Vuser type.
Please contact Mercury Interactive to renew your license.”我们公司穷啊买不起loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！
最起码在VUGen中运行该脚本我们可以得到任意一个SQL语句及存储过程的执行时间，如果我们测试的B/S结构的程序，我们也可以通过HTML协议录制的脚本在CONTROLLER中监控SQL SERVER服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了
第二篇：使用Loadrunner性能测试经验总结
教程贴士：明确压力点，根据压力点设计多少种场景组合
第一步：计划测试
1、明确压力点，根据压力点设计多少种场景组合
2、把文档(包括多少种场景组合、场景与场景组合条件的对应表)写好
3、如果监测UNIX机器，在被监测的机器需要安装监测Unix的进程
4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据
5、让开发人员做一个恢复数据的脚本，以便于我们每次测试的时候都能够有一个相同的环境
6、针对每一个模块包括四个子文件夹：如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹，每个子文件夹储存对应的文件，如下表所示
其中：结果名“1场景”是在场景中的“Results Setting”中设置的，具体的设置见“建立场景”部分，这里也可以有另外一种方法：在打开模板设置，如下：
选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名，当你打开某个lrr文件时，系统自动在当前目录中生成一个文件保存分析图表，如下图所示：
第二步：生成测试脚本
1、 把登陆部分放到“vuser_init”部分,把需要测试的内容部分放到“Action”部分执行;但是如果是模拟多个用户登陆系统，则要把登陆部分放到Action部分来实现
2、 录制脚本后，想查询某个函数的原型，按“F1”键
3、 确认脚本中哪些参数是需要进行参数化的(最好能可以和开发人员一起确认)
4、 在脚本参数化时把函数web_submit_data()中的ITEMDATA后面的数据参数化，因为这些数据是传递给服务器的，当然也可以把一个函数中的所有相同变量都替换掉
5、 脚本中无用的部分用“/*”“*/”“//”注释掉，但最好不要删除
6、 调试脚本遵循以下原则：
确认在VU里SUSI(单用户单循环次数single user & single iteration)
确认在VU里SUMI(单用户多循环次数single user & multi iteration)
确认在controller中MUSI(多用户单循环次数multi user & single iteration) 确认在controller中MUMI(多用户多循环次数 multi user & multi iteration)
7、 事务的名称取的有意义便于事务之间的区分，把所有的事务名都记录在一起，便于在测试结果概要中区分它们，这要写成一个表：某次测试有哪些模块，每个模块中有哪些事务(见对应的“关系表”)
8、 在 “Parameter List”中可以选择参数类型“Random Number”，使某一个参数取设定的范围内的随机值
第三步：建立场景
1、 把场景名称编号，并制定出一份场景名称和场景条件组合的对应表。比如，场景m对应于“某一模块_xx个vu _分z台machine”(见“关系表”中的例子)
2、 根据上面的对应表把场景设置好，需要设置的要素如下：总体多少个用户、分多少个组、每个组有多少个用户、分几台机器运行、每个脚本迭代多少次、是否回放think time时间、检查Parameter List中每个参数设置是否正确、参数从表中取值间隔是否正确、是否选中“Initialize all Vusers before Run”
3、 测试结果应该保存为“m场景0，m场景1,…”
4、 把虚拟用户分散到几台机器上和在一台机器上面都要进行测试，因为有可以效果不同
5、 场景中如果有需要改动的地方，必须新建一个场景(建议使用“另存为”，然后再修改结果文件名，再选择相应的脚本)，并把场景按顺序编号，先维护好场景与场景组合条件的对应表，以便以后的查找，并且在结果 “Results Setting”中设置的结果名与场景名相同。建议在“Results Setting”中选中“Automatically create a results directory for each scenario executeon”让它每次自动累加，不建议选中“Automatically overwrite existing results directory without prompting for confirmation”，因为我们不要覆盖掉以前的测试结果，把它保存下来以便有个根据。
6、 需要注意的地方：当在“Parameter List”中的“Select next row”选中“Unique”时，如果再在“Edit Schedule\Schedule by Scenario\Duration”中选中第二项“Run for XX after the ramp up has been completed”时系统就会报错，提示“Unique”类型不相符。