性能测试问题小结

1）测试代码要有延续性
我开始做aranda的时候已经是1.1.0版本，上一版本（aranda-1.0.0）的很多测试代码都没有去延用，都是自己搞了一套，不仅工作量大大增加，而且不利于回归测试。所以以前的代码一定要延用。
2）多线程去读取同一文件，造成某些线程长期饥饿，最显著的特征是响应时间过长，TPS变低。后来通过内存模拟文件流（bytearraystream）
3）jmeter传参数不能在jmeter图形界面上点击添加，那样是无效的。必须在性能测试脚本中包含一个getDefaultParameters的方法。(比如缩放参数，图片路径等只需改变参数不许再写另外一个类似的脚本)。
4）三个概念，beforeclass, beforeobject, beforerun,(假设有10个线程在不停的跑)
Beforeclass:指第一个执行的线程执行一次，其他9个不执行
Beforeobject：10个线程每个线程第一次执行的时候都执行一次，后面就不再执行
Beforerun：10个线程每次run的时候都执行
上传图片的时候，需要获取不同的token，所以必须放在beforerun里面执行，一开始我们放在beforeobject就没法得到token了（白跑了一晚上。。。）。
5）后台启动的脚本，有时候想去杀它找不到那个后台启动的进程号，可以用pstree –p。
6）长时间跑（跑稳定性），如果抛异常的话，一定要把jmeter.log删掉，如果抛一晚上的异常的话，这个文件很大很大，可能有撑爆磁盘的风险。跑性能测试的时候，特别是晚上跑的，因为跑的话一定要确保磁盘不会爆。
7）性能测试代码结构：ArandaBaseTest去继承AbstractJavaSampleClient，
AbstractJavaSampleClient中的一些方法：
在性能脚本中添加参数 getDefaultParameters()
实际跑的 runTest(JavaSampleerContext context)
初始化 SetupTest（JavaSampleerContext context）
后期处理 Teardowntest(JavaSampleerContext context)
具体的性能脚本都去继承ArandaBaseTest，根据实际情况重写其中的一些方法
8)过载情况。因为对系统的性能本来就没有很好的估计，性能测试结果有可能出现过载情况，比如相同条件下，50并发情况下，响应时间是1000ms；100并发情况下，响应时间是2000ms以上，那么可以看到50并发的时候系统可能已经过载了。最好能把过载的那个点找出来。
9）GC可能会引起CPU的剧烈波动。因为大规模GC时可能会挂起很多线程，导致CPU瞬时下降。可以用jstat –gcutil pid time(ms) 查看GC情况（jstat –gcutil 27584 1000）
10)常用jstat记录：
Jstat命令 效果
Jstat –class pid 显示加载class的数量级所占空间等信息
Jstat –compiler pid 显示VM实时编译的数量等信息
Jstat –gc pid 查看GC的次数及时间，
S0  — Heap上的 Survivor space 0 区已使用空间的百分比
    S1  — Heap上的 Survivor space 1 区已使用空间的百分比
    E   — Heap上的 Eden space 区已使用空间的百分比
    O   — Heap上的 Old space 区已使用空间的百分比
    P   — Perm space 区已使用空间的百分比
    YGC — 从应用程序启动到采样时发生 Young GC 的次数
    YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
    FGC — 从应用程序启动到采样时发生 Full GC 的次数
    FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
    GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
Jstat –gccapacity pid 可以显示vm内存三代中（young,old,perm）对象的使用和占用大小。其中PGCMN（MX）：最小（最大）perm内存使用，PGC：新生产的perm内存使用，PC当前perm内存使用量，OC是old内存的占用率，其他类推吧。。。。
Jstat –gcnew pid New对象的信息
11）cache情况。这个问题卡了2天，在图片操作进行中，从nas那边进来的图片可以被aranda服务器能够cache起来，看了下数据，能够cache11个G以上，所以被cache起来的图片不再需要去nas上拿，这样就造成了aranda服务器网络io只有出去，没有进来的现象。用一个不干任何事情的helloworld程序，去吃掉这些cache，命令为：java –Xms 10240m –Xms12024m –jar Helloworld.jar 39999999,内存就会被事先分配掉，从而不会造成11G以上的cache，实际只有1G多一点cache。然后利用随机图片生成函数，生成不同的图片30G以上，把aranda服务器每次要读取的图片在cache中命中的概率降到很低，这样aranda服务器每次进行加水印等操作时图片很少可能在cache中，都必须去nas机器上拿，故aranda服务器的网络流量就会达到大致相等。
12）一定不要去研发的代码里面加我们的测试监控代码。碰到这样的情况要push研发加监控代码，然后暴露接口出来给我们QA用。在测试hessian连接池的时候需要监控socket的打开数，关闭数等数据，所以在研发的代码中加了监控代码，一开始是没有问题的，但是下一次再从主干更新代码的时候出现冲突了。
流程方面：
1） 每个迭代都必须要进行TC评审，且确保TC评审必须要有作用。在项目过程中，TC中漏掉了几个接口（有几个是在当时迭代未做实现，后来添加的），但是在TC评审中未指出这些漏掉的接口，故在回归的时候才补上去的，不是很合理。
2） 在小迭代开发模式中，冒烟测试不是很合适，因为基本上一个小迭代就几个功能点，研发经过自测，且小迭代周期较短，如果执行测试退回的话，研发短时间改一下就会再次提交测试，所以可以一开始预测试一下，有明显问题就叫研发改一下，再继续去跑所有用例。
3） 性能测试的场景和指标最好叫需求方或者研发定出来，哪怕是他不确定的期望结果，但是平台项目确实比较难定具体指标，拍脑袋不如我们自己直接去预跑一下，可以每个场景跑几分钟，Aliper工具可以实时监控到TPS和响应时间，把结果反馈过去，然后可以帮助研发出期望值。在此之后再来确定场景和指标，就有了根据。