一次数据库压力测试的故事

发表于:2019-3-27 10:36

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:空白葛    来源:博客园

  前言
  最近配合某客户做了一个关于XX系统的压力测试,其实经过和客户的沟通得知,客户此系统上线后压力并不大,但由于应用方前期的表现不是特别尽如人意,对此不太信任,所以要求本次压力测试着重观察。
  参与方
  我、客户、应用方(我和客户简称甲方,应用方简称乙方)
  环境配置
  数据库:RAC一体机集群(为方便统计,应用统一链接一个节点)
  压测工具:jmeter
  压测场景
  大概10个大场景,每个场景有100、200、300 3个级别的并发小场景,每个小场景压测10分钟
  压测数据量
  压测数据为应用方编造,数据库大小2G,其中涉及的关键业务表数据量大概有40万,10万,3万不等的数据
  压力测试
  此前也做过很多次压力测试,对于数据库方面来说,主要是搜集服务器当时的CPU,内存使用,以及关注AWR报告SQL执行部分是否有异常,便于正式上线后,系统资源的分配,从压测数据量来看,2G数据可以说是很小的数据量,另外并发最大300,对于2G数据来说,也不算大,本以为压力测试可以顺利进行,那也只是理想很丰满。。。。
  插曲一
  在测试其中一个场景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、良好的沟通是客户服务的第一环节,或许你能力暂时不够,但不能糊弄客户,谁都不是傻子

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号