昨天加班到晚上10点半左右，跟项目组同事出去喝酒到12点半左右。
激情四射呀。
回来近1点半才睡觉，结果早上五点多就醒了，这什么作息？！
坚持着接着睡，一直睡睡醒醒到下午三点多才算是缓过来。
然后就看到两点半左右，一个我之前培训过的客户发来信息说有个性能问题要看一下。这个客户明天晚上就发了个dump文件让我分析。
今天才有时间仔细看看。他说jdbc上从5个换到50个，性能反而下降了。我拿过dump翻了一下，看到有大量的等待。
然后发过来几个图。
jmeter40个线程时，jdbc5个：
jmeter60个线程时，jdbc5个：
这两个图看似是线程数不一样，其他都不变的情况下，比对TPS是合理的。但是我问了下他们的执行策略。是线程数一次性加上。
对于这样的策略，我觉得没有什么可比性。看了下响应时间，60个线程时平均响应时间在766ms，40个线程时平均响应时间是519ms。这个时候，我想问，一个线程的时候响应时间是多少。他说，不知道，没这么测试过。
既然不知道那怎么知道一下上40个线程呢？
这个就是关键问题了。
我在项目中经常说，要先做基准测试，就是要知道响应时间的最初是在什么级别，后面再计算下要上多少线程。
从上面的tps图来看最多120个，假设基准响应时间在0.1s的话，这个应用也最多就支持10个线程。而加到40、60个线程的时候，基本上就没有正常的数据了。
所以我让他把线程的增加策略改为1分钟增加1个线程的方式，结果得到如下图：
响应时间图：
TPS图：
从tps图来看，用户增加到4个的时候，就已经没有tps的稳定增加了，也就意味着这时候是拿响应时间来换tps了。
但是从响应时间上来看，由于图中的比例过大，导致前面根本看不出来响应时间的增加趋势。我让他给我看了一个用户时候的平均响应时间，那时才63ms。
所以这时候，往后的测试策略就是，要把场景最大值设置为5或6个用户，每个用户增加之后持续时间长一些。再来看响应时间的变化。
然后再来分析瓶颈在什么地方。
而直接上20、40、60个线程的方式，在测试过程中，已经远远大于了系统能支撑的最大压力。
这时候再想分析压力已经拿不到有效的数据了。并且在这时拿到的数据可能都是因为瓶颈导致的紊乱的数据，也不能说明是那里就有性能瓶颈。比如说文章一开始的dump，这时数据就是完全乱了。
所以对于性能分析来说，执行策略也是非常重要的前提条件。
