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

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