淘宝商城(天猫)高级技术专家.3年研发+3年性能测试调优/系统测试+4年团队管理与测试架构、研发系统实践. 新舞台新气象, 深化测试基础架构及研发架构,希望能在某个技术领域成为真正的技术大牛。欢迎荐才http://bbs.51testing.com/viewthread.php?tid=120496&extra=&page=1 .邮件: jianzhao.liangjz@alibaba-inc.com,MSN:liangjianzhao@163.com.微博:http://t.sina.com.cn/1674816524

一次性能测试结果排查过程

上一篇 / 下一篇  2009-02-13 01:09:28 / 个人分类:loadrunner性能测试经验

查看( 940 ) / 评论( 3 )
一个测试环境受到外部不预期的干扰,性能测试结果将出现不预期的数据,导致分析困难甚至错误结论。
最近碰到一个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 编辑]

TAG: 性能测试 结果分析 排查 oracle 日志切换

dcwang2005发布于2009-02-13 09:43:45
学习了。正在学loadrunner。
lijian422202发布于2009-02-19 10:51:07
liangjz你好,我也做过类似的测试,主要是用AOP方式加入一些服务,观察上service的response time 比不上service的response time还要低,这里和你描述的一样,但TPS也就是服务器的吞吐量是不上service的高。。所以我在报告中也是没有好的解释,所以只是以TPS来衡量上service对系统的影响。
yuandjing的个人空间 yuandjing 发布于2009-02-19 13:16:42
呵呵,自己性能测试做的比较少,梁兄的帖子要顶的
我来说两句

(可选)

Open Toolbar