前段时间在项目中实践性能测试,遇到很多问题,现在沉淀分享一下,避免大家在做的时候也绕弯路。
一、性能测试环境的搭建:
1、  申请机器:要注意申请机器的时候保持和线上的机器同样的配置(操作系统及位数、CPU、内存、JAVA_OPTS),避免反复多次申请,很浪费时间。注意不要忘了申请压测机。
以上信息的查询地址是:
http://app.ops.taobao.net/javahost/
http://pesystem.taobao.net:9999/main/
如果在第一个地址中找不到有关JAVA_OPTS的信息,可以登陆第二个系统,用跳板机登陆线上机器,进行查看JAVA_OPTS的配置,在/home/admin/应用名/bin 下的jbossctl文件。
2、  性能环境的搭建有2个沉淀(我是后面才得到这两个沉淀的,走了一些弯路):
环境搭建:
http://baike.corp.taobao.com/index.php/%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA
环境配置:
http://baike.corp.taobao.com/index.php/%E7%8E%AF%E5%A2%83%E9%85%8D%E7%BD%AE
照着沉淀来做就可以了。
3、  申请到性能服务器后,注意核对机器位数:
查看性能机器的位数:uname --a
本同学曾经没注意线上机器的位数,导致申请的性能机器位数和线上的服务器不一致,后面又申请了一次,浪费了一些时间。
4、  申请到性能服务器后,进入到 /home/admin 目录下,需要清理下该目录下的内容
sudo -u admin rm -rf 所有的文件夹名称
按文件夹删除
切忌不要执行rm -rf *  防止隐藏文件被删除!
5、  我们通常的做法是将日常服务器下的/home/admin下的内容远程拷贝到性能服务器下的/home/admin目录下,使用scp命令,但是我每次运行总是提示没有权限,或者可以运行上面沉淀中提到的命令,遇到问题可以向冷之、耿电、SCM求助。
6、  我们需要修改一些antx.properties的配置,使用命令vi antx.properties 命令。一些公用的应用都有专门的性能环境,我们依赖的应用环境应该变成性能测试的hsf的版本号,直接把daily改成 perf 即可,具体原则是:只要是性能环境下有的应用 ,就直接将daily改成perf,若没有,则用功能环境,即不做修改,例如:
tgs.consume.ic.version  = 1.0.0.perf
channelpoint.consume.item.service.version =1.0.0.perf (consume表示作为消费者)
具体的基础应用的性能环境情况可以参考 http://confluence.taobao.ali.com:8080/pages/viewpage.action?pageId=97911282。
同时,我们还要把我们的被压的应用发布为某个hsf的版本,例如:
channelpoint.provide.shine.version  = 1.0.0.perf
tgs.provider.queryservice.version  = 1.0.0.perf  (provide 表示对外提供服务)
(这里的1.0.0.perf 只是个hsf 的版本号,只要能和日常环境使用的版本号区分开即可 )
7、  到/home/admin/work目录下 将项目的代码checkout下来。使用命令 svn co ,查看 svn 版本信息:svn info。
8、  修改一些oracle和mysql 的配置文件,改成性能库的地址,一般是在这个地方:/home/admin/应用名/conf/下有 mysql 或 oracle 的配置文件。打开修改。
9、  重新build,执行sudo --u admin ./build.sh.
在build的时候可能会遇到一些问题,比如不能执行mvn 命令,这时候就要查看环境变量了,使用export 命令,如果发现环境变量中path少了一些内容,执行一下 source .bash_profile 命令。(更细节的东西请查看第二个沉淀中的内容)
10、              确认应用是否发布成功,注意查看日志,
一般是 /home/admin/应用名/logs/下面,跟应用相关的日志文件,看有没有报错。
还有一个是有关hsf 的日志文件,记录了该应用是否注册为hsf服务,具体的存放位置可以跟开发同学确认。
11、              发布成功后,到性能环境的平台上查一下hsf服务
http://perf.config.taobao.net:8080/config-ops/conn_mgr.html,如果能查到,就表示性能环境已经搭建ok了,呵呵,第一关顺利通过。
二、性能测试的数据准备
1、业务数据
2、基础数据
比如我们的搜索模块,业务逻辑是每次从TGS 搜索100条线下商品库数据,从主站的搜索引擎搜索100条商城数据,将200条数据再重新排序。而线上有300w的TGS数据,可以分析出每一次查询TGS的业务数据是100,这些数据必须保证是在IC库中存在的,并且是正确的数据,基础数据就是为了扩大表的数据量而自动造的数据,可以不是真实存在的。
3、UIC基础数据的构造:比如用户数据,有个地址可以将日常下的用户信息导入到性能环境中 http://perf.uic.daoshuju:8080/uicConsole/
三、性能测试脚本的编写
1、页面测试
2、socket(还未做尝试)接口测试
3、java vuser 接口测试(本次项目采用的是这种方式)。
接口测试所要求的响应时间为小于100ms,而页面则一般要求小于500ms。
四、细说压接口的注意事项
1、这个接口要访问我们的应用,本身是作为消费者的身份的,所以在编写bean 的 xml 配置文件的时候,要写成
<bean  class="com.taobao.hsf.app.spring.util.HSFSpringConsumerBean"  init-method="init">
注意:provider 和 consumer的属性名是不一样的,不要写错。
2、要使该接口能跑起来,还依赖一些接口定义的jar包等。我的做法是用mvn命令打包一下,在package\XXX.war\WEB-INF\lib 下面的jar包全部拿过来,这样就不会有遗漏。
3、用java vuser 写就像写我们的接口测试用例一样,一定要确保测试脚本在功能环境下能够调通,再放到压测机上进行压测。
五、执行场景,简单分析
在数据、环境和脚本准备完毕,并且调试成功后,开始进入执行阶段。此阶段主要包括两部分内容,一部分是监控,另一部分是分析。
  1. 通过Loadrunner获取压测数据,包括TPS、响应时间、服务器资源等,并判断性能测试是否通过,是否存在问题(靠loadrunner分析图表得出)。 
  2. 通过对应用后台的日志,分析潜在的问题和风险,看这些log有没有异常。
  3. 通过对Loadrunner趋势图的分析,看应用虽然满足期望,但是否存在波动,波动范围是否超出预期。标准差根据数理统计的概念得来,标准差越小,说明波动越小,系统越稳定,反之,标准差越大,说明波动越大,系统越不稳定。包括响应时间标准差、TPS标准差、Running Vuser标准差、Load标准差、CPU资源利用率标准差、Web Resources标准差等。tps波动模型:
被测系统种类 测试是否通过 测试类型 超时概率 采样时间*(s)* 可接受的最大波动范围
JAVA接口 性能测试 低于万分之一 1 5%~8%
JAVA接口 稳定性测试 低于万分之一 60 5%~8%
JAVA Web 性能测试 低于万分之一 1 4%~6%
JAVA Web 稳定性测试 低于万分之一 60 4%~6%
4.  通过工具监控,有很多工具可以监控服务器端的CPU、内存情况,这里就不再说明。
5.  最后,再次强调下性能测试方案的设计,这一点很重要。设计方案应该在项目组内做评审,如果是初次做性能测试,最好邀请性能测试的同学参加评审,特别是要调用外部应用的时候,性能测试设计方案评审时一定邀请该应用相关的开发同学。尤其是查询类的需求,并且有统计数量的功能时,一定要明确查询的基数是多大,本次我们的失误就是在评估这个基数的时候出了问题。