性能测试 and BIEE(一)

 

目标：

1.       性能测试的方法

2.       BIEE 的部分技术点

3.       从错误中学习

 

什么是性能测试？

1，  响应时间

a)         报表

b)         ETL 批处理

c)         OLTP 事务

2，  系统影响

a)         资源使用情况

b)         扩展性

从经验的角度去看，性能测试包含如下点：

1，  是否足够快 ? 是否我的报表运行的时间满足用户的规定或者期望？

2，  负载情况。当每一个人访问时，是否运行的还是足够快速？一个新的报表系统对已有的系统是否会造成不良影响？负载测试进一步扩展做压力测试，看一个系统的扩展型如何。

 

性能测试 VS 负载测试

负载测试不是性能测试，它属于性能测试的范畴。

性能测试 (performance testing)

重复的发起请求获取数据，决定性能是否可接受。可接受是主观上的，由用户需求来决定。在 OBIEE 的情况下，我们就看 answer 和 dashboard 是否足够快从而让用户感到满意。

负载 (load testing)

1，  量化应用对系统的影响

2，  在负载的情况下，应用性能是否可接受

一张报表在单独访问时，可能没问题。但是如果某一天，大量的用户在同一个时间段登录系统进行访问，运行报表，是否还抗的住 ?

 

为什么要进行性能测试？

1，  检查系统运行情况

a)         是否用户都很满意

b)         是否在用户的期望时间内返回数据

2，  提供基线

a)         多快才算快？多慢才算慢？

b)         如果不知道之前系统的运行情况，如何知道现在系统性能变差了呢？

c)         假如已经做了测试，并且定义了很多性能指标，当出现问题时，比较容易定位问题

d)         当你认为修复了性能问题时，可以进行校验。是否已经修复问题？是否导致其他地方除了问题？

3，  验证系统设计和构建系统的方式

a)         分区和索引的效果

b)         不用老听 DBA 说“ it depends ” , 要用数据说话

c)         比较这次的并行优化设置或者分区策略的效果是否与上一次有很大的不同

d)         一个索引可能对某种报表有效果，但是如何知道它没有影响其他的报表呢？除非有重复的测试可以立即知道是否有问题。

e)         提前做测试，了解应用的性能，而不是让客户进行大量的抱怨后再进行优化

4，  容量规划

a)         是否要扩容，增加机器 ? 负载均衡？

5，  It’s never too late

a)         “ You’ll never catch all your problems in pre-production testing. That’s why you need a reliable and efficient method for solving the problems that leak through your pre-production testing processes.”

b)         性能测试不是可选的。它是强制的。它仅仅取决于你何时进行测试。尽管你可能对自己的应用的性能很自信，但是你是否知道系统的当前运行状况，比如 CPU,IO ？系统能够支持的用户量到底有多少？防患与未然，总比事后弥补容易的多。

c)         会让你更加擅长自己的工作，因为性能测试要求对系统有彻底的了解。

 

总结下： what & why

What- 量化响应时间，系统影响

Why- 用户期望，问题诊断，设计校验

 

如何进行性能测试

先看一下整体的步骤，下面会详细分析每一步如何做。

 

 

定义测试 (Define&build your test)— 将要测试什么？

定义 (define)

1，  测试的目的

2，  测试的范围

3，  前提条件

4，  规范

5，  数据，环境等

 

构建 (build)

1，  OBIEE 规范

 

如果测试的目标不明确的话，可以采用如下的两种选择：

选项 1 ：自上而下 / 从大处着手 (Top down/Start big)

1，  最短时间内测试得到初始结果，尽管不能够划分问题

2，  如果时间有限的情况下，先解决已发现的问题。找到速赢的方法。

3，  不够精确

比如，查看 usage tracking 中的所有运行时间超过 5 分钟的报表，只针对这些报表进行测试。

选项 2 ：自底向上 . 从小处着手 (Bottom up/start small)

定义测试的组件，记录每个测试的结果，然后组合这些测试组件成为更大的测试案例，进而扩展到负载测试。

1，  最终更加精确

2，  更多的度量 = 更精确 = 更快识别问题

3，  比较枯燥

4，  更长的过程，要求更高的精度

比如，来自于用户的报表响应时间需求，展示的工作负载

 

测试必须是隔离并且可重复的，否则你如何知道你修复了问题，而不是使得问题更糟糕？

Repeatable

在哪些方面需要运行同样的测试 ? 比如 schema 定义，数据库配置的参数， OBIEE NQSConfig,OBIEE rpd,OBIEE reports ， presentation service config & web cat

 

Isolatable

一套独立的性能测试环境

 

考虑测试边界 ( 范围 )

1，  更多的部分 = 大量的错误

2，  减少复杂度

3，  不要减少关注点，而是要提取出问题的本质

4，  找到瓶颈的最上游点

 

对于 OBIEE 有很多测试点，需要找到哪种是最合适的？是否需要运行所有的测试进行直接数据库访问？

最终目标是保持简单，避免不必要的复杂度。

如果已经能够识别出问题区域，就没必要还浪费时间，查看所有地方 .

这个原则同样适用于 OBIEE 。依赖于 report,rpd 和你的数据模型以及数据库，性能瓶颈可能发生在任何一个地方。但是这不是让你查看所有的地方，有如下原因：

1，  你的测试表明相应很慢。你是愿意考虑 3 个地方还是 300 个地方呢？当我们在分析问题时，很清楚的是， BI server 返回数据给 Presentation service 的时间是很快的。所以我们可以排除 presentation service. 记住你的依赖点以及存在耦合的点。一般时间都花在数据库查询方面，但是我们无法直接编辑 sql ，因为这个 sql 是 bi server 自动生成的。

2，  另一个你应该降低复杂度的原因是考虑变更对测试计划的影响。如果根据你的测试结果，需要做变更，那么相应的要考虑对测试做哪些调整以及重新配置你的监测点，是 2 个还是 20 个呢？

 

OBIEE stack

 

 

以上的图描述了一次用户请求的处理过程：

用户发出报表请求， PS 将逻辑 sql 发送给 BI server ， BI sercer 将 SQL 发送到数据库服务器，数据库服务器将结果返回给 BI server ， BI server 对数据做一些处理 ( 聚集，裁剪 ) ， BI server 将数据返回给 ps server ， ps server 通过 web/app server 将结果呈现给用户

 

OBIEE 的测试options

 

 

如何做我们的测试？下面会列出所有的选择，然后给出为什么选择这个，而不是那个。

测试必须是可重复的，即意味着自动化。

从自上而下来看，有如下几种方式：

1，  模拟完全的端到端系统

a)         一个用户和一个秒表

b)         一个 web 兼容的测试工具，比如 load runner 或者 Oracle Application Testing Suite ，来模拟用户与 OBIEE 的仪表盘或者 anwser 的交互过程

c)         或者某种像 web services 一样聪明的东西

 

2，  如果仅仅测试 BI server

a)         可以利用 OBIEE 自带的工具 nqcmd 。它通过 ODBC 跟 bi server 进行交互。

b)         可以使用另外 ODBC 兼容的工具进行测试

 

3，  最后，你可以在数据库直接运行 sql 。但是这个不是很容易，请记住， BI server 产生 SQL.

a)         哈哈，你有多少次，听到 DBA 向你咆哮，负载飚上去了。。。我反正有好几次。。

b)         BI server 产生 sql 就是一个黑盒。你能够做的就是通过在数据库中以及 rpd 里进行良好的建模来保证 sql 尽量优化。

c)         如果仅仅需要修改执行计划，那么可以节省很多时间， OBIEE 就无需关注，完全就是数据库的事情了。可能需要评估新的索引，并发或者压缩的设置。

如果对数据感兴趣，可以针对数据库做相应的优化，针对 Oracle 数据库如如下建议：

1，  SQL file run through SQL*Plus from the command line (lends itself to scripting)

2，  SQL Tuning Sets, which you can feed into SQL Performance Analyzer to run on another database

3，  Oracle RAT  - real application testing (which is made up of Database Replay and SQL Performance Analyser)

 

Oracle RAT-real application testing( 由数据库回放以及 SQL Performance Analyser) ，对于参数的调整，索引的优化，可以进行对比，查看性能的变化情况，从而对是否变更进行决策信息指导。

 

Nqcmd

Nqcmd 是 OBIEE 安装后的部件之一，在 unix 和 windows 上都存在。

可以进行界面交互，也可以通过脚本进行调用。

Command: nqcmd - a command line client which can issue SQL statements

                 against either Oracle BI server or a variety

                 of ODBC compliant backend databases.

SYNOPSIS

         nqcmd [OPTION]...

DESCRIPTION

         -d<data source name>

         -u<user name>

         -p<password>

         -s<sql input file name>

         -o<output result file name>

         -D<Delimiter>

         -C<# number of fetched rows by column-wise binding>

         -R<# number of fetched rows by row-wise binding>

         -a (a flag to enable async processing)

         -f (a flag to enable to flush output file for each write)

         -H (a flag to enable to open/close a request handle for each query)

         -z (a flag to enable UTF8 instead of ACP)

         -utf16 (a flag to enable UTF16 instead of ACP)

         -q (a flag to turn off row output)

         -NoFetch (a flag to disable data fetch with query execution)

         -NotForwardCursor (a flag to disable forwardonly cursor)

         -SessionVar <SessionVarName>=<SessionVarVAlue>

 

如果在 unix 上执行 nqcmd 命令，请确保配置了环境变量。

 

脚本自动化测试

 

1，  产生一些 logic sql 文件

2，  使用 unix 的 shell 脚本或者 windows 的 power shell 脚本

3，  顺序的执行逻辑 sql 文件，向 BI server 发出请求

 

脚本的内容模拟了用户的交互，并行的执行 nqcmd 命令，可以多次执行。

脚本需要包含如下特点：

1，  随机访问

2，  休止

3，  记录日志到文件

4，  SQL 交互，触发 SQL 调优集收集

最终的目的是模拟用户请求，收集到响应时间的数据。

 

脚本的并发查询过程如下图：

 

 

也可以利用一些现有的测试工具，比如 load runner

Load runner 的特点：

1，  模拟用户交互过程 -HTTP Traffic

2，  强大的但是不容易安装 —Ajax 使得事情复杂了

 

需要考虑是否真的需要该工具。

也可以结合其他的工具， fiddlers 或者 firebug

 

综上，对测试的定义进行一个简单的总结：

1，  需要非常清楚测试的目的。

2，  也许需要定义多个测试

3，  OBIEE 的不同测试点，选择最适当的点进行测试

4，  把过程以及结果记录下来