测量以及监控 (measing and monitoring)
在很多环节会产生日志信息，对日志进行分析可以有效的得到关注的数据。
1， web 层日志
a) web server ，比如 apache 日志，是用户请求进来的第一道关卡日志
b) App server ，比如 oracle application server
c) Presentation service plugin,Analytics- 当你从 Analytics 得到 500 错误时需要查看的日志
2， Presentation 日志
a) Sawserver.log ，默认情况下，该日志记录的东西不多。需要修改 logconfig.xml 文件，这样可以收集更详细的日志信息。
b) 该日志对于分析问题很有用，同时也提供解各个环节的花费时长精确细节。比如收到请求到发送逻辑 sql 到 BI server ，以及到接收到返回数据的各个时间点。
3， BI server 日志
a) 查看 NQQuery.log 日志，包含了逻辑 SQL ，物理 SQL ，以及 BI server 的执行计划，数据库的响应时长。
b) 可以看到该日志文件中，将查询过程分为很多个处理节点，比如， aggregation ， post-aggr ， sort ， DbGageway Exchange ， Projection( 映射 ) 等。
c) 还有 NQServer.log 包含 BI server 的启动日志，链接数据源，初始化变量的信息
4， 还有一些系统管理功能，提供了详细信息。比如 PerfMon 或者 BI Management Pack for OEM(oracle 企业管理器 ) ，你也可以使用 JMX 协议的工具，比如 jconsole 或者 jManage 去访问数据。
5， 针对数据库，遵循标准的监控方法，取决于你用的是哪种数据库。对于 Oracle 而言，你可以使用 OEM ， ASH ，或者 SQL Monitor 等。
6， 对于系统的 IO,CPU 情况，利用一些系统工具进行统计。比如 Oracle OS watcher 或者 PerfMon 等。 EM 的性能功工具很强大。如果做纯粹的测试的话，要获取性能数据的话，你就需要去查看 V$SQL_MONITOR 表。
NQQuery.log 的内容格式大致如下：
Query Status: Successful Completion
Rows 1, bytes 96 retrieved from database query id: <<10172>>
Physical query response time 1 (seconds), id <<10172>>
Rows 621, bytes 9246 retrieved from database query id: <<10188>>
Physical query response time 10 (seconds), id <<10188>>
Physical Query Summary Stats: Number of physical queries 2, Cumulative time 11, DB-connect time 0 (seconds)
Rows returned to Client 50
Logical Query Summary Stats: Elapsed time 14, Response time 12, Compilation time 2 (seconds)
以下是 Oracle SQL Monitor 的工具截图： ( 以 HTML 在页面上清晰的展示数据 )
测量总结：
1， 有很多种方法去度量
2， 尽量的自动化 ( 更容易，更少的错误 )
3， 决定什么指标跟你的测试有关
a) Load testing- 系统指标
b) 单独的报表进行性能测试 - 也许只需要关注相应时长
分析 (Analyse)
分析的步骤如下：
1， 收集数据
a) 存储格式化数据
b) 原始数据
2， 标记你的测试
a) 最好使用无意义的标签
3， 进行分析
a) 可视化
b) 分析结果依赖于测试的目的，比如 load testing ，识别瓶颈
c) 形成趋势，与基线进行对比，利用 excle 或者条件格式，颜色标记，进行凸显。
分析数据的方法：
1， 平均值 (Average/mean)-- 经常被使用，但是忽略了方差 (variance)
2， 百分比 -- 比较直观
3， 标准偏差 -- 体现出方差
4， 样本数 — 统计的有效性
记录测试的数据
对于每一个测试执行需要记录每一级与下面如何相关：
比如 Logic SQL -> SQL IDS ， SQL IDS -> exec plan id
也许看起不变，但是我们可以在测试间做些变更：
1， 修改 RPD 可以导致逻辑 SQL 变更，相应的回引起物理 SQL,SQL ID, 执行计划的变更。
2， 新的索引不会改变物理 SQL 或者 SQL ID ，但是有可能导致执行计划的变化
扩展 usage tracking
以下过程是可选的，在分析的结尾，很有可能需要做些修改 ( 分区，系统配置 ) ，重新测量数据。当决定迭代时，需要决定做什么？
1， 更多的测试？
a) 索引列表
b) 配置
c) 等等
2， 测试错了吗？
a) 重新定义
3， 完成了所有的测试
a) Review
分析总结：
1， 与测试目的进行比对
2， 分支
a) 全部实现？
b) 继续测试
3， 结论，证明了什么，又推翻了什么？
4， 是否还需要做更多的测试？
5， 还有时间做更多测试吗？
6， 是否需要重新定义新的测试集？
回顾 (REVIEW)
实现 (Implement)
1， 莫要忘记验证你的实现
2， 使用你的性能测试脚本
3， 基线 & 性能测试
4， 当你在线上遇到性能问题时，可以利用你预定义的测试去确定范围以及问题点
备注：基线的作用：当你修复了慢的报表，那么之前快的报表是否变慢了呢，这就是通过基线来进行识别。
- 查看图片附件