http://www.taobaotest.com/blogs/qa?bid=12278
前段时间在项目中实践性能测试，遇到很多问题，现在沉淀分享一下，避免大家在做的时候也绕弯路。
一、性能测试环境的搭建：
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 配置文件的时候，要写成
- 通过Loadrunner获取压测数据，包括TPS、响应时间、服务器资源等，并判断性能测试是否通过，是否存在问题（靠loadrunner分析图表得出）。
- 通过对应用后台的日志，分析潜在的问题和风险，看这些log有没有异常。
- 通过对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. 最后，再次强调下性能测试 方案的设计，这一点很重要。设计方案应该在项目组内做评审，如果是初次做性能测试，最好邀请性能测试的同学参加评审，特别是要调用外部应用的时候，性能测 试设计方案评审时一定邀请该应用相关的开发同学。尤其是查询类的需求，并且有统计数量的功能时，一定要明确查询的基数是多大，本次我们的失误就是在评估这 个基数的时候出了问题。