风控性能测试结束了

 

反欺诈经过一周的性能测试，问题找到了也算是解决了。具体效果还得看真实环境。

 

数据库服务器的配置:16U,16G内存,Oracle 10G

测试工具:Road runner

 

主要涉及到的表6张，其中三张将近200万数据，另三张各将近20成。

 

中间经历了服务器无法正常响应,响应过慢,数据库CPU和数据库负载过高.

这些其实都与一个数据的执行效率有直接关系。因为风控设置的规则,特别是频率规则全部统计查询,十分耗资源.

第一感觉是检查SQL和优化数据库.

于是检查了SQL,去掉了一些不必要的表关联,再将相关表建上索引,可仍然没有明显改进.于是想到是不是因为大表关联响应性能了,打算合表,

之后和同事的沟通以及DBA的确认,认为大表关联还不是目前主要的问题.后来也证明了这一点.其实主要原因是表上的索引没用上。这跟oracl数据库的索引策略有关,当需要访问的数据超过所有数据的15%后 会导致索引全扫描。这就是数据集中的问题。

因为测试的时候某些字段是一样的,而SQL语句正好使用到这些字段查询,这就不可能走索引了。后来根据DBA的建议，手工将数据打散，打散

成1:100,即1%的数据重复率。效果马上显现出来了。起码能正常响应，只是速度还稍慢。DBA再建组合索引以及更改执行计划。性能再次提高

，实践证明执行计划优化很重要(目前线上环境的oracle采用基于成本的策略)。所有这些都做完以后离目标还是有挺大距离，到这时，DBA的结论是

从数据库方面来讲主要的性能提升方法已经用完了。说到底还是数据集中问题。根据数据统计的top 25大buyer订单率,再次将数据打散成1:1000,这时候执行几十个统计查询一共花费的平均时间为400多毫秒。

 

其实这里面最主要的问题就是数据集中。因此做性能或压力测试时要注意这方面的问题。当数据不是问题的时候组合索引和计划任务优化