测试基准数据的准备(r6笔记第29天)

在很多时候我们都需要做一些对比测试，比如我们的机器换了一个平台，比如机器做了较大的硬件升级和改造，或者引入了第三方的软件服务等等，很多时候就需要做一个基准测试，想根据测试结果然后对比做了一些变更之后，性能是提升了还是下降了，或者提升了，提升幅度有多少，这个单纯来估算一个值既不科学也不准确。这个时候还是想做一个基准测试，来得到一个数据报告，让数据来说话。 当然绝大多数的时候，如果想做这样一个测试，出发点是好的，但是说实话，落实起来真是难上加难，一来要推动业务部门配合，来从前端发起相应的数据处理请求，来进行基本真实的模拟场景，或者说根据以往的经验来通过第三方的工具来实现，类似于压力测试的方式。这样也可以模拟出一个业务高峰来。 上面的两种方法都是目前主要采用的一些方法，如果从系统的角度来看，从DBA的工作量来看，都需要做很多的前期工作，比如我们要模拟业务高峰期的情况，总得有数据吧。很多时候都是从生产环境中去抽取，然后加上开发部门的配合，可能有些job,damon都有一定的环境依赖，可能需要调整一些参数等等。如果是压力测试这种方式，如果让专门的性能测试团队来做，对于他们来说，一个前提就是对于业务很熟悉，要不很难短时间模拟出很多有效的数据来。然后把这些数据和业务流程结合起来。 上面两种方式都可以实现，都需要熟悉业务和需求。 如果我们把这个工作解耦，交给第三方的独立结构来做，那么上面两种方式就彻底不可用了。 第三方测试可能更具有说服力，完全都是依照数据来说话，没有半点含糊或者水分的东西。比如我们确实需要这么做，不过一个最重要的顾虑就是数据的安全性，我们不希望把自己的所有系统都完全暴露给第三方，我们还是需要保留一些东西的。所以第三方的测试有优点但是有顾虑。怎么去合理把握这个度呢。 比如我们有10套应用系统对应10个独立的数据库实例，那么我们想把他们做一个整合，然后想看看硬件升级之后是否在性能上能够提升。 这个时候我们可以按照下面的思路来考虑。我们可以根据讨论来初步决定一个数据的基准范围，比如我们得到了近两个星期的数据负载信息，然后我们就运用这个数据库级的负载信息来做分析，比如我们抓取几个有代表性的时间段，比如在负载高峰时段+几个业务正常时间段，然后得到对应的awr报告。 通过这些报告我们就能够基本得到一些基础数据，比如在高峰时段，tps是多少，事务的大小，都能够做到心中有数。 比如一个awr报告是这样的。

Load Profile

我们就可以清楚的看到tps在238左右。每个事务的大小在1k左右。每秒钟的数据调用次数在1000多 然后我们进行筛选，根据这些数据得到一个整体的概念，然后在awr中尝试抓取一些典型的sql语句，比如某些sql语句执行频率特别高，哪些sql占用的IO资源特别高等。 根据这个我们就可以基本得到一个sql清单，比如sql控制在20个以内，20条sql语句是我们需要关注的，可以列入基准范围内， 然后根据sql来得到访问的表，这样既进一步来分析表的数据情况，比如涉及的表有10个，3个大表数据在亿级，3个中级表，数据量在百万，3个小表数据量在几千 我们得到了这些数据情况，就可以进一步来提供种子数据，比如我们拿出表中的几条数据来作为种子数据，然后提供一个基准，比如那些字段的值需要唯一，那些字段的值是枚举类型的，选择的值需要在一定的范围之内，或者说哪些表有特定关联关系等等。 比如可以提供如下的数据方式

然后我们可以提供数据的翻倍规则，比如表test_data数据量有1000万，我们就可以根据翻倍规则得到数据应该怎样去扩展，那些值的范围是有效的。

然后在此基础上我们需要提供一些性能指标，比如某些sql语句在10分钟内执行频率在100万次。那么我们就可以提供这些数据来尝试模拟这种情况。多条sql有采用这样的方式就可以得到一个基本的概览图，然后结合事务做一个评估，那些语句放入在一个事务内，最大事务包含多少sql语句等等。 最后提供一个基准数据，比如下面的这种方式。

最后提出我们的期望，这样基础数据的提供就有了一些依据，而不是根据自己的感觉来做了。尽管在评估中还是有一些误差甚至大的差别但是很多时候我们能够把一些重要的指标给过滤出来，集中分析。