关于生产上删除redis脏数据的一次测试

上一篇 / 下一篇  2016-03-16 16:39:29 / 个人分类:功能测试

最近接到一个测试任务,发现生产上大量的rediskey值未设置过期时间,这几个key的实际有效时间是当天,结果设计过程未考虑到过期时间问题,而导致生产上每天产生几十万的脏数据。由于redis的数据全部存储在内存,导致内存每天成数量级增长。开发提供一个shell脚本,在redis服务器上根据日期删除无效的脏数据。

 

接到该任务,我吸取之前犯过一次错误(一次测试存储过程,和开发合计沟通了数据量就测试,而不考虑生产上的实际数据量。导致存储过程到了生产跑不动,因生产数据量比我们预计的要多出很多)。

 

我开始第一轮测试

第一步,开始找运维分析生产数据,根据运维查询一天的结果进行了生产删执行脚本的时长分析。分析出数据总量,单次查询量和循环查询次数,统计出查询时长。删除时长考虑到是精确到key名称,整体时间根据查询时长给了一个估值。

第二步,测试大数据量情况下的时长以及redis服务器的资源消耗情况

第三步,根据以上两者的情况给出上生产环境的建议

完成第一轮并给出测试报告后,项目组认为资源长时间不释放,会导致生产上的业务数据可能超时,于是修改开发方案,减少每次删除的量,删除一批后停顿n秒。

 

第二轮测试

主要是根据之前测试场景和测试数据,对比资源使用情况。测试完成后,发现cpu仍长时间在40%左右,仍然担心造成生产业务数据超时。再次分析,发现按日期模糊查询占用了大量的时间。此时项目组内讨论要减少查询次数,思考再三,发现只有一个key值是无法精确定位的,其他的key值是可以根据生产数据定位到具体的key

 

第三轮测试

主要也是根据之前测试场景和测试护具,对比资源使用情况。因为在同一时间段内,测试同样的数据量,对应的key值一天的数据量就提高到了之前的三倍,这时发现脚本执行报错——Argument list  too long此时,心里一紧,发现自己的测试场景覆盖不全。一天的数据量没有达到实际的要求。

再次多番检查,决定还要到生产上查一下其他的key值情况,此时还发现其中的两个key在生产上和我们预计的不同,业务根本没有使用起来,对应的脏数据并不多,如果没有发现该问题,又要造成大量的空查询。

开发修改了删除数据的范围,使其同生产实际数据相符。

再次多番检查和测试,给出对比数据。确定资源使用情况不会影响生产业务,删除数据范围正确,测试场景模拟够全面,终于结束测试。

 

我个人认为在整个测试过程当中,我是保持这尽职尽责的态度去实施的,但是,每轮测试发现的问题,都在警示我,做测试有时候并不只需要技术上的能力(读懂shell脚本),更考验这实际情况分析能力和多方面的沟通能力,能从复杂的问题中去粗取精,找到问题的核心点,多方面证明这个程序的有效性。


TAG:

chen111的个人空间 引用 删除 chen111   /   2016-04-06 09:34:11
总结得很好
 

评分:0

我来说两句

Open Toolbar