成功测试
成功测试

您现在的位置: 成功测试简介_成功测试分数 > 成功测试分类 > 一次数据库压力测试的故事

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

发布时间:2021/3/21 8:41:13   点击数:
福州白癜风医院 http://pf.39.net/bdfyy/bjzkbdfyy/140721/4429411.html
点击上方蓝色字   最近配合某客户做了一个关于XX系统的压力测试,其实经过和客户的沟通得知,客户此系统上线后压力并不大,但由于应用方前期的表现不是特别尽如人意,对此不太信任,所以要求本次压力测试着重观察。

参与方

  我、客户、应用方(我和客户简称甲方,应用方简称乙方)

环境配置

  数据库:RAC一体机集群(为方便统计,应用统一链接一个节点)

  压测工具:jmeter

压测场景

  大概10个大场景,每个场景有、、个级别的并发小场景,每个小场景压测10分钟

压测数据量

  压测数据为应用方编造,数据库大小2G,其中涉及的关键业务表数据量大概有40万,10万,3万不等的数据

压力测试

  此前也做过很多次压力测试,对于数据库方面来说,主要是搜集服务器当时的CPU,内存使用,以及   在测试其中一个场景A并发,jmeter压测工具开始报错(具体报的什么错,暂不追究),乙方给的恢复是数据量太大,达不到,继续下一个场景B,并发,在进行完这个并发的场景后,就有了如下对话。

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

  乙方(压测人员):

经理这个我不是很懂,你帮忙看下。

  乙方(经理):这个我找人处理的,十万条数据数据量比较大,实际没有那么大的

  甲方:这在测试呢你们数据清理了?

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

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

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

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

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

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

插曲二

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

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

  乙方(压测人员):10分钟个并发,这么多次;10分钟个并发,应该不会变成2倍吧。

  乙方(压测人员):这个是总次数吧?

  甲方:是。

  乙方(压测人员):那我觉得这个没问题吧?

  乙方(压测人员):你说的这个暂时记录着,回头他们看下。

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

  乙方(压测人员):所以今天先的跑了吧。

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

插曲三

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

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

  乙方(压测人员):我问下去。

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

  乙方(经理):刚刚那个是地区省份的筛选。

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

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

  乙方(压测人员):你一问,我看了一下。

  乙方(压测人员):xx分析的脚本,之前调的时候有部分禁掉了。

  乙方(压测人员):重新跑下xx分析吧,我停了。

  甲方:。。。。。。。。。。。。。。。

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

总结

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

  对于我来说,有以下感悟:

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

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

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

推荐阅读

点击阅读?超详细|每个人都能看懂的Web网站压力及性能测试案例

点击阅读?怎样正确做Web应用的压力测试

点击阅读?简单的WEB程序压力测试

点击阅读?JMeter压力测试教程(入门篇)

点击阅读?LoadRunner实现Android/iOS手机压力测试(实例)

上文内容不用于商业目的,如涉及知识产权问题,请联系小编(--)。

戳“阅读原文”一起来充电吧!在看点一下大家都知道预览时标签不可点收录于话题#个上一篇下一篇

转载请注明:http://www.81guangchang.com/cgfl/12408.html

网站简介 | 发布优势 | 服务条款 | 隐私保护 | 广告合作 | 合作伙伴 | 版权申明 | 网站地图

当前时间:


冀ICP备20001468号-10