一次数据仓库报表测试(2)

1.背景

      最近终于将这个项目测试结束了,之前写过一篇文章,写的是测试过程中遇到的问题,感兴趣的同学可有先去看看上一篇文章。

2.目的

      项目结束后问题也没有得到根本解决。宝路由此引发了一些列的思考,今天想跟大家聊聊。

3.引发的思考

     前一篇文章写了压测报表系统时的问题,问题抛给某厂商后,厂商人员来了两次做现场支持,然而效果并不理想。深问其产品底层原理,为什么内存回收后会导致,报表系统的“不可用现象”,然而。。。。。。

     在这里吐槽下,派来支持的人,远程桌面怎么最小化都TM的不清楚,我也是醉了。

思考1:脚本采用匿名登录的方式来查询报表。

    先解释下这里所说的匿名登录,其实就是个白名单,将执行脚本的机器的ip增加值白名单,然后可以通过指定的url来获取token,再拿这个token来访问指定报表。这样就避免了登录系统的步骤。(因为他们自己都没解决登录系统的密码加解密问题,当时也跟他们聊了为不能提供登录密码的加密方式,然而回复却是,目前他们自己测试也是采用匿名登陆方式)。

    这样的脚本就极其简单,发送请求获取token,再发一个请求(带token)来查看报表,这种方式是否合理?试想真实环境中用户是这种场景么?显然不是。。。。。试想下这样的方式与真正用LR录制出的脚本相比是不是会少了好些页面请求?

思考2:忽略思考时间这种压测方式到底有没有问题

   这又要说到,前篇文章测试中提到的压测问题。采用忽略思考时间这种方式压测,报表系统长时间压测就会出现前篇文章中所说的问题。这里又要说到OLTP,OLAP

什么是OLAP:联机分析处理

什么是OLTP:联机事务处理

   我们常见的接口压测(说的再范围一些就平常的增、删、改、查)都是属于OLTP , 然而OLAP 一般就是数据仓库系统的主要应用,用来分析大量OLTP形成的数据,说白就是对这些历史数据进行加工分析,读操作较多。

   最后解决方案就是,增加pacing值,3s , 4s ,5s 分别进行了尝试。其实就是对之前的脚本进行了弱化(从发起压力角度来说),这样更贴近真实的业务场景。本来在线用户就少,其实远未达到忽略思考时间的那种查询密集度。现实中也不可能存在业务人员疯狂在不停的查询报表。

  但最后还是要说下,忽略思考时间的这种方式本身没有问题。确实不太合适当前的场景,假如真的就是存在这种场景,或者说我就要看你系统在高点击率下的性能表现,那么就要采用这种方式了。

   问题又来了,在这种高点击率下,长时间(大概20min)的压测,系统却出现了不可用的现象且短时间不可恢复,需要手动重启产品的某个服务才可以,这种现象我觉得是不ok的。这就需要产品人员深挖其原因,是不是产品缺陷导致的。

posted @ 2019-11-03 14:34  宝路  阅读(288)  评论(0编辑  收藏