一个测试环境受到外部不预期的干扰，性能测试结果将出现不预期的数据，导致分析困难甚至错误结论。

　　最近碰到一个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处理数据长度随机变化有关。