这是一篇关于数据库压力测试的故事

　　最近配合某客户做了一个关于XX系统的压力测试，其实经过和客户的沟通得知，客户此系统上线后压力并不大，但由于应用方前期的表现不是特别尽如人意，对此不太信任，所以要求本次压力测试着重观察。文章源自玩技e族-https://www.playezu.com/20962.html

• 参与方

　　我、客户、应用方（我和客户简称甲方，应用方简称乙方）文章源自玩技e族-https://www.playezu.com/20962.html

• 环境配置

　　数据库：RAC一体机集群（为方便统计，应用统一链接一个节点）文章源自玩技e族-https://www.playezu.com/20962.html

　　压测工具：jmeter文章源自玩技e族-https://www.playezu.com/20962.html

• 压测场景

　　大概10个大场景，每个场景有100、200、300 3个级别的并发小场景，每个小场景压测10分钟文章源自玩技e族-https://www.playezu.com/20962.html

• 压测数据量

　　压测数据为应用方编造，数据库大小2G，其中涉及的关键业务表数据量大概有40万，10万，3万不等的数据文章源自玩技e族-https://www.playezu.com/20962.html

　　此前也做过很多次压力测试，对于数据库方面来说，主要是搜集服务器当时的CPU，内存使用，以及关注AWR报告SQL执行部分是否有异常，便于正式上线后，系统资源的分配，从压测数据量来看，2G数据可以说是很小的数据量，另外并发最大300，对于2G数据来说，也不算大，本以为压力测试可以顺利进行，那也只是理想很丰满。文章源自玩技e族-https://www.playezu.com/20962.html

　　在测试其中一个场景A 300并发，jmeter压测工具开始报错（具体报的什么错，暂不追究），乙方给的恢复是数据量太大，达不到300，继续下一个场景 B，100并发，在进行完这个100并发的场景后，就有了如下对话。

　　甲方：xxx表数据 上一个场景A 300并发时，还是10万 ，这个场景B 100并发的场景跑完变成3万条了。

　　乙方（压测人员）：@经理 这个我不是很懂，你帮忙看下。

　　乙方（经理）：这个我找人处理的，十万条数据数据量比较大，实际没有那么大的

　　甲方：这在测试呢 你们数据清理了？

　　甲方：今天把你们做测试数据的表和对应的数据量都写到方案里确定下来。

　　甲方：不要测试过程中删数据。

　　甲方：不能为了达到并发标准在哪删数据，达不到就是达不到，后期可以优化的。

　　甲方：确定下来 测试过程中不要做小动作。

　　乙方（压测人员）：删数据这个我就不知道了，一般压力测试的时候都不会让他们做什么操作的。

　　从上面的对话，大概对情况有一个了解，乙方可能是认为，数据量大所以场景A 300并发报错，在没有和甲方沟通的情况下，私下清理了主业务表数据量，不巧被甲方发现，甲方大为不满。其实压力测试就是为了确认系统的运行压力，如果都和乙方那样，私下清理数据，也就失去了压力测试的实际意义，在此，给各位奋战的DBA 和 应用人员一个建议，实事求是，实时沟通。

 

　　由于压力测试，每个大场景都有3个不同并发级别的小场景，但是在分析AWR报告时发现，其中SQL执行次数部分并没有明显的变化，100并发SQL执行次数30000，200并发SQL执行次数30000多，根据以往的压测经验来看，这肯定是有问题的，同时在系统CPU使用来看，也证明了这一点，两个不同级别的并CPU使用并无明显差异，然后甲方乙方开始。

　　甲方：100和200在数据库后台执行的SQL次数没有太大差别

　　乙方（压测人员）：10分钟100个并发，这么多次；10分钟200个并发，应该不会变成2倍吧。

　　乙方（压测人员）：这个是总次数吧？

　　甲方：是。

　　乙方（压测人员）：那我觉得这个没问题吧？

　　乙方（压测人员）：你说的这个暂时记录着，回头他们看下。

　　乙方（压测人员）：你说的情形，我咨询过了， 可能会涉及到修改对应的一个服务里面的参数。

　　乙方（压测人员）：所以今天先100的跑了吧。

　　看到这里，基本明白了，前面几个并发测试等于是白测试了，这也告诉我们，做事还是细致点好，同时要说服乙方，就要拿出证据，免得双方扯皮，怪不得客户提前都说，这次压力测试要着重点看。假如只是为了应付工作，简单的搜集点数据，然后事后再分析，那反工时必然的，吃一堑长一智。

　　压力测试终于到了最后3个场景，对于前几个CPU压力表现还算正常，起码是有压力的，但最后3个场景的CPU压力几乎没有，难道是一体机的性能太好？那也不应该，再说这个场景是关于客户分析，市场分析的场景，从字面意思看，应该会访问很多数据表才对，这次又实实在在的分析各个运行的SQL，以及具体涉及的业务表。

　　甲方：上个场景 客户分析中 XXXX表是什么表？

　　乙方（压测人员）：我问下去。

　　甲方：那个客户分析的场景 数据库服务器几乎没压力  后台显示访问比较多的是这张表。

　　乙方（经理）：刚刚那个是地区省份的筛选。

　　甲方：哦 客户分析 后台的数据来源 只有这一个主表么？

　　就在这时，乙方测试人员发了一个哭哭的表情，我就意识到问题有出现了。

　　乙方（压测人员）：你一问，我看了一下。

　　乙方（压测人员）：xx分析的脚本，之前调的时候有部分禁掉了。

　　乙方（压测人员）：重新跑下xx分析吧，我停了。

　　甲方：。。。。。。。。。。。。。。。

　　看来甲方最开始的不信任还是有依据的，这个压力测试在此之前，乙方已经准备了一周左右，但还是出现各种状况。

　　针对此次测试，除了插曲一乙方做的不地道之外，另外2个都是乙方前期准备的问题，在此，我们不对乙方做过于‘积极’的评价。

　　对于我来说，有以下感悟：

　　1、不管是对自己或者客户，做事要以主人公的心态，抱着应付了事，害人害己呀，比如案例中XX方

　　2、和其他环节的人员沟通不确定性问题时，需要拿出确凿证据，免得双方踢皮球

　　3、良好的沟通是客户服务的第一环节，或许你能力暂时不够，但不能糊弄客户，谁都不是傻子。