51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【周活动】 找茬--心里圈的故事 !【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【103期】:如何快速掌握软件测试工具! 【专访】商莉:如何从零开始做好接口自动化 【干货】各大公司测试大牛职场晋升宝典 自学软件测试那点事
查看: 4207|回复: 3

[原创] 一次性能测试结果排查过程

[复制链接]

该用户从未签到

发表于 2009-2-13 01:03:14 | 显示全部楼层 |阅读模式
一个测试环境受到外部不预期的干扰,性能测试结果将出现不预期的数据,导致分析困难甚至错误结论。
最近碰到一个CASE,将一个sevice  插入测试环境的网站应用中,然后对比是否加入这个service的性能影响。
多台测试机器,每台机器部署多个应用,所有应用共享一个DB。

  系统架构: java + webx+ ibatis+ oracle。

        另外,这个service采用几百K的数据运行速度也在毫秒级别。
       
        呵呵,差点掉到沟沟里,特记录下。
       
一 制定测试方案

和service开发的dev 评审测试方案。 没有和网站应用的架构师核对。
被测服务器 load 已经大于 1 。


二 性能测试执行过程

选取一个post 产品的流程做性能测试脚本。性能测试数据从几百个byte-几K.
调整JAVA应用参数与生产环境同。

1) 删除用户数据
2) 删除日志
3) 重启应用
4)交替执行service上与不上场景.
5)多次执行去性能数据平均值

性能测试选择在晚上人少时执行。


三 性能测试结果分析

性能测试发现average response time,上与不上service 相差无几,都是0.13秒左右 。甚至同样并发数时,上service的response time 比不上service的response time还要低。
其他load <2 ,cpu%约20% ,iowait% <1%,内存充足都相近。这个结果似乎有点解释不通。

另外比较反常的是:average reponse time图(非graph average)上偶尔有锯齿型的到达0.2 甚至0.4的高点,尺度延续时间40多秒。average response time的 std dev(标准方差)约 0.13甚至更高。
经web page break down分析图片这个数据更加清晰可见。


经咨询网站的同事,架构师,DBA,可能多台机器上有应用定时器(quartz框架)或者DB自身定时器干扰,与网络无关。
选择关闭上述所有应用定时器以及DB层定时器后,晚上重新执行多个场景的性能测试,并手工定期检查DB执行SQL。


再分析性能测试结果,依然有锯齿型数据且性能结果且很接近之前结果,但这个数据是可控程度高的数据。
用SQL查询性能测试期间DB 日志:
select SEQUENCE#,FIRST_TIME from v$log_history
  2  where
  3  FIRST_TIME >=to_date('20090209 19:00:00','yyyymmdd hh24:mi:ss')
  4  and FIRST_TIME<to_date('20090209 23:00:00','yyyymmdd hh24:mi:ss')

发现有4个日志切换过程。

对比average reponse time拐点与日志切换时间点,部分与之吻合,但average reponse time拐点长度偏大。
经咨询每次日志切换约有20-50毫秒事务挂起。

另外部分不吻合部分,是service处理数据长度随机变化有关。

四 常见工具

再回头看看确认环境干净,参数配置预期正确的工具。

毫无疑问,好用的脑子是最强的武器。

1) OS 层面
ps ,top 看进程
ipcs    看进程间通讯
netstat 看网络连接
nmblookup,nbtstat 连接的人

sysctl,/proc  看系统参数
ulimit   系统软、硬限制

2)apache 层

httpd.conf

3) mod_jk 层
几个 property文件

4)JBOSS 层
run.conf,run.sh以及应用配置参数

另外就是检查对应启动的服务,可以借助 web-console
5) JVM 参数

6) DB 层面
oracle init file
mysql show variables

7) 其他关联服务。
如 memcached

...

从上例看到,性能测试排除干扰很重要,在系统日趋复杂的情况下需勤开口、善借外力,力争一次把事情做对、做好

[ 本帖最后由 liangjz 于 2009-2-13 01:06 编辑 ]
回复

使用道具 举报

该用户从未签到

发表于 2009-2-13 09:43:45 | 显示全部楼层
学习了。正在学loadrunner。
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2009-2-19 10:51:07 | 显示全部楼层
liangjz你好,我也做过类似的测试,主要是用AOP方式加入一些服务,观察上service的response time 比不上service的response time还要低,这里和你描述的一样,但TPS也就是服务器的吞吐量是不上service的高。。所以我在报告中也是没有好的解释,所以只是以TPS来衡量上service对系统的影响。
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2009-2-19 13:16:42 | 显示全部楼层
呵呵,自己性能测试做的比较少,梁兄的帖子要顶的
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /2 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2019-6-25 16:33 , Processed in 0.070218 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2019 Comsenz Inc.

快速回复 返回顶部 返回列表