希望认识做性能测试的朋友,共同学习提高。

性能测试项目反思

上一篇 / 下一篇  2009-06-09 10:39:58 / 个人分类:性能测试

现在一说性能测试、性能调优,好多人首先想到的是用LOADRUNNER等测试工具,好像没有这些工具就不能进行性能测试就不能进行性能调优。真是这样的吗?其实工具
固然重要,但更重要的是系统的分析、测试案例的设计。正好刚刚结束了一个软件性能测试的项目,有些感触,整理一下,也为了给大家一个参考。
      前段时间一直在搞自动化测试框架SAFS、STAF等方面的东西,那个确实比较难搞。领导突然安排去做一个性能测试项目,已经近4个月没有搞性能测试了,心里
确实有点没有底。配置的人员也比较少,并且经验也不足。我们首先分析了系统架构、业务特点、运维数据。发现系统的性能和用户数的多少并没有太多的关系,
初步确定是因为某些模块的程序编写有性能缺陷。在运行程序时,明显发现有些功能响应缓慢。因为时间比较紧,并且测试环境并不是独立供性能测试使用,功能
测试也在同一环境下进行,并且还没有给我们开通数据库DBA权限和服务器操作系统的超级用户权限,限制非常多,所以我决定分两步进行,让其他同事编写性能测试
测试案例和脚本,我来分析系统响应时间缓慢的原因,初步判断应该是数据库方面的原因。因为给我开通的数据库用户只有查询权限,所以我只能用SQL语句来查询
追踪后台运行的SQL,通过select sql_text,sql_id,users_executing,executions, loads from v$sqlarea;来查询后台正在执行的SQL,通过得到的SQL_ID查询SQL语句
select * from v$sqltext where sql_id ='75yzszjxyrrva',然后根据HASH_VALUE得到完整的SQL,select * from v$sql where hash_value='2079055722'.捕获SQL后发现
两条SQL语句运行较慢:1、select b.case_id,report_no,report_time,b.organ_id,realname,accident_time, reporter_name,accident_type,certi_type,register_id, recorder_id,  certi_code,  accident_status, has_image, accident_type, diff_date,   to_char(max(ti2.scan_time), 'YYYY-MM-DD HH24:MI:ss') as scan_time from (  select distinct tcc.case_id,tcc.case_no as report_no,tcc.report_time,tcu.real_name as realname,tcc.accident_type, tcc.accident_time,tcc.register_id,tcc.reporter_name,trc.certi_type,trc.certi_code,tcc.accident_status,tcc.recorder_id,tcc.organ_id,tcc.case_type,  sysdate - trc.insert_time as diff_date,decode(ti.case_id, null, -1, 1) as has_image  from t_report_case trc ,t_claim_case tcc,t_customer tcu,t_image ti ,t_employee te where trc.case_id = tcc.case_id  and tcc.case_id = ti.case_id(+)  and tcc.register_id = te.emp_id  and tcc.register_id = 3381221 and tcc.insured_id = tcu.customer_id(+)  and tcc.case_status=4  and tcc.case_type = te.case_type   )b  , t_image ti2 where ti2.case_id(+)=b.case_id     group by b.case_id,report_no,  report_time,      b.organ_id,       realname,       accident_time,       reporter_name,       accident_type,       certi_type,       register_id,       recorder_id,       certi_code,       accident_status,       has_image,     accident_type,       diff_date order by has_image desc,report_time asc

执行用时6.672秒。2、(   select tpp.prem_id,tpp.policy_id,tpp.fee_type,tpp.pay_mode,           tpp.fee_status,tpp.actual_prem,tpp.due_time,tgp.holder_id as customer_id,           tgp.send_code,tgp.policy_code as policy_code, tpp.policy_type,          tpp.insured_id,tif.insured_num,' ' as notice_code      from t_policy_prem tpp,t_group_policy tgp,t_insured_first tif    where  ((tpp.fee_status=0 and tpp.pay_mode in(1,2))or(tpp.fee_status in(0,3,4) and tpp.pay_mode=3))      and tpp.fee_type= :1      and tpp.insured_id=tif.insured_id(+)      and tpp.policy_id=tif.policy_id(+)      and tpp.policy_type = '2'      and tpp.policy_id = tgp.policy_id      and tgp.send_code = :2  )  union  (   select tpp.prem_id,tpp.policy_id,tpp.fee_type,tpp.pay_mode,           tpp.fee_status,tpp.actual_prem,tpp.due_time,tp.holder_id as customer_id,           tp.send_code,tp.policy_code,tpp.policy_type,           tpp.insured_id,tp.insurant_num as insured_num,' ' as notice_code      from t_policy_prem tpp,t_policy tp    where 1=1      and  ((tpp.fee_status=0 and tpp.pay_mode in(1,2))or(tpp.fee_status in(0,3,4) and tpp.pay_mode=3))      and tpp.insured_id is null      and tpp.policy_type in ('1','3')      and tpp.fee_type= :3      and tp.send_code = :4       and tpp.policy_id = tp.policy_id     )    order by due_time,fee_type
执行用时4.8秒左右。分析这两条SQL语句的执行计划,SQL1的COST值是一个天文数字,SQL2的COST的值是1700多,不算太高。明显第一条SQL语句需要优化,分析SQL1后
建议优化为:select b.case_id,report_no,report_time,b.organ_id,realname,accident_time, reporter_name,accident_type,certi_type,register_id, recorder_id,  certi_code,  accident_status, has_image, accident_type, diff_date,   to_char(max(scan_time), 'YYYY-MM-DD HH24:MI:ss') as scan_time from (  select distinct tcc.case_id,tcc.case_no as report_no,tcc.report_time,tcu.real_name as realname,tcc.accident_type, tcc.accident_time,tcc.register_id,tcc.reporter_name,trc.certi_type,trc.certi_code,tcc.accident_status,tcc.recorder_id,tcc.organ_id,tcc.case_type,  sysdate - trc.insert_time as diff_date,decode(ti.case_id, null, -1, 1) as has_image,scan_time  from t_report_case trc ,t_claim_case tcc,t_customer tcu,t_image ti ,t_employee te where trc.case_id = tcc.case_id  and tcc.case_id = ti.case_id(+)  and tcc.register_id = te.emp_id  and tcc.register_id = 3381221 and tcc.insured_id = tcu.customer_id(+)  and tcc.case_status=4  and tcc.case_type = te.case_type   )b       group by b.case_id,report_no,  report_time,      b.organ_id,       realname,       accident_time,       reporter_name,       accident_type,       certi_type,       register_id,       recorder_id,       certi_code,       accident_status,       has_image,     accident_type,       diff_date order by has_image desc,report_time asc
修改后的执行用时是0.047秒左右。
第二条SQL比较麻烦,通过用具体数据替代绑定变量执行速度很快,而在程序中却很慢,真的不知道是什么原因,与开发人员通过写日志逐行对代码进行检查,发现
在receivedao.java文件中checkFullARSENDCODE(String s)函数中有这这行代码,
preparedstatement.setLong(4, Long.parseLong(s));检查数据库,SENDCODE字段是字符型,传递的参数却是LONG型,

更改为:preparedstatement.setString(4, Long.parseLong(s));

效率明显提高,因为在SQL语句中传入的参数类型错误,如果传入的是长型就不走索引了,是全表扫描。这样的错误还真不好发现啊!

通过这个例子,可以发现,不用自动化工具,不用编写脚本就可以发现一些明显的性能瓶颈的。

TAG:

 

评分:0

我来说两句

我的栏目

日历

« 2024-03-22  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 10073
  • 日志数: 17
  • 建立时间: 2008-06-30
  • 更新时间: 2010-03-04

RSS订阅

Open Toolbar