一次性能测试结果排查过程
一个测试环境受到外部不预期的干扰，性能测试结果将出现不预期的数据，导致分析困难甚至错误结论。最近碰到一个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
2where
3FIRST_TIME >=to_date('20090209 19:00:00','yyyymmdd hh24:mi:ss')
4and 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 编辑 ] 学习了。正在学loadrunner。 liangjz你好，我也做过类似的测试，主要是用AOP方式加入一些服务，观察上service的response time 比不上service的response time还要低，这里和你描述的一样，但TPS也就是服务器的吞吐量是不上service的高。。所以我在报告中也是没有好的解释，所以只是以TPS来衡量上service对系统的影响。 呵呵，自己性能测试做的比较少，梁兄的帖子要顶的
页:
[1]
