2.4 基于工作单元的响应时间分析优化方法论
2.4.1 UOWTBA优化方法论的导入
在RTA工作方法论的基础上，Craig Shallahamer结合吞吐量和响应时间关系曲线图提出了基于工作单元的响应时间分析方法论（Unit of Work Time Based Analyze，UOWTBA或者Unit of Response Time Analyze，UOWRTA）。UOWTBA方法论相较于RTA方法论而言，在强调响应时间时，同等强调了吞吐量的重要性，它通过衡量操作单元的响应时间而不是绝对时间来完成性能优化。
工作单元的最简单说法就是某个特定操作粒度之上的操作，比如一次逻辑读、一次物理读、一次latch gets、一次mutex gets、一次parse call等。工作单元的粒度根据需要分析的场景而定，相对来说，由于工作单元的时间响应需要作为顶层业务作业的可比较单元，所以需要选择相对基础的细粒度工作。
再次来看吞吐量和响应时间关系曲线。
吞吐量和响应时间关系曲线极为明确地揭示了一个本质现象：任何输出响应时间都是在特定的输入吞吐量下才会表现出其业务价值的。UOWTBA优化方法论强调了输入吞吐量单元，其响应时间总是标记为单个输入吞吐量单元的响应时间。
性能优化的目标就是延长曲线突变点，从而使其可以获得更高的吞吐量。TBA关键的问题在于缺乏衡量吞吐量的基础标准，或者对于每个业务系统都具有其特定吞吐量描述，这样就给TBA分析带来巨大的困难。比如CRM业务系统，其标准吞吐量为：每小时5000个受理、20000个开通等描述，但会发现你无法把这些描述和数据库的监控关联起来。
Oracle数据库有很多标记吞吐量的指标变量，比如executes、user calls、transactions等，事实上，Oracle 11gR2的RTA方法论中也涉及了衡量基于executes、user calls、transactions等输入吞吐量的输出响应时间。大家可以很明显地看到，虽然从业务输入层面上transactions、executes都是可以感知的输入吞吐量的，但是execute和execute、transactions和transaction之间的个体差异太大，使其输入吞吐量缺乏一致性比较的基础。比如执行10万次的SQL语句“select from dual”自然无法和执行10万次的SQL语句“select from dba_objects”相比较。transactions也是同样的道理，除了一些业务极为均匀的系统外，无法作为吞吐量输入衡量的基础。
为了获得一个通用的业务特征和吞吐量的描述，笔者在TBA的基础之上进行了进一步的研究，希望获得更好的描述访问特征和访问能力的监控指标，以更有效地完成TBA分析。Craig A. Shallahamer的研究成果正好和我所寻求的方向一致，基于工作单元的TBA分析方法可以很好地弥补TBA方法的不足。
2.4.2 输入吞吐量指标的选择
衡量任何一个业务系统的运行性能，可以从两个基本方面来进行考察：访问特征和访问能力。
访问特征体现了业务系统运行的负载特征，主要用来衡量吞吐量。当一个业务系统的访问特征发生了变化，特别是其访问特征预期在吞吐量突变点之上时，可以判断业务系统的性能将会发生变化。或者说业务系统的访问特征发生了明显的变化，可以猜测以下两点正在发生：
1）有新的业务正在加入，需要引起关注。
2）原有业务的访问特征发生了变化，可能会引起重大的性能问题。
访问能力体现了业务系统运行的响应时间特性，主要用来衡量响应时间。一个性能表现良好的系统，响应时间或者访问能力必须控制在可接受的范围之内，否则就表示业务系统性能不佳。
数据库应用系统在考虑数据库黑盒子的情况下，可以用两个基本性能指标来衡量访问特征和访问能力：LIO（逻辑I/O）和PIO（物理I/O）。Craig A. Shallahamer就是选择了LIO和PIO作为输入吞吐量操作单元，尤其是LIO输入指标。一般来说，数据库应用运算量很小，绝大部分数据库应用的运算转换消耗可以忽略不计，LIO基本可以代表CPU资源的消耗运行。
任何业务系统在不考虑运行和网络交互的情况下，都可以归类为两类基本的操作：LIO和PIO。每个业务系统不管其业务模式如何变化，SQL语句如何多变，其最终有效性都可以通过这两个指标来衡量。以每秒或者每分钟多少个LIO和PIO来衡量业务特征，LIO和PIO的数量和两者之间的比例就构成了现有业务系统的运行特征，而LIO和PIO具有相互转换的关系甚至可以归结为一个衡量业务系统运行的指标。
在引入LIO和PIO两个核心输入吞吐量指标之后，就可以构建UOWTBA响应时间分析方法论的基本形态。
访问特征：每秒运行的LIO和PIO数量。
访问能力：每个LIO和PIO的响应时间。
辅助描述：Transactions，User Calls，Execute数量。
响应时间（LIO）= 服务时间 + 等待时间
响应时间（PIO）= 服务时间 + 等待时间
对于PIO来说，可以进一步分解为：响应时间（PIO） = 服务时间 + I/O服务时间 + 其他等待时间。
再次查看吞吐量和响应时间曲线，以及图2-4基于输入吞吐量PIO的响应时间曲线。
可以看出，UOWTBA和TBA最根本的区别在于，UOWTBA分析对吞吐量的描述比标准TBA分析更加清晰，使基于业务的TBA分析可以简单地转化为基于技术的TBA分析。
2.4.3 采用UOWTBA优化方法工作
简单观察基于输入吞吐量LIO或者PIO的响应时间曲线，从工作单元分析可以发现存在三类问题。
1）LIO或者PIO在没有达到基线标准的情况下发生了性能变异。
2）LIO或者PIO在达到或者超过基线标准的情况下发生了性能变异。
3）LIO或者PIO的特征发生了变化，从而导致了性能变异。
不同的性能问题可以有不同的考虑方向。
第一类问题：可以考虑配置变更或者资源提供者发生了故障，比如存储电池故障会导致cache失效。
第二类问题：期望的性能异变，可以从降低业务运行特征的数量（LIO和PIO）来考虑问题，使其回到突变点之下，并重新建立吞吐量突变曲线。这种变异基本可以考虑以下三个不同原因。
1）业务量发生变化。
2）数据规模发生变化。
3）访问的终端数量发生变化。
第三类问题：基本可以考虑两个原因。
1）原有业务的访问特征发生变化，比如SQL语句的执行计划发生变化。
2）有新的业务加入。
从以上分析可以看出，与TBA方法论的缺乏落地能力总是会导入OWI方法不同，UOWTBA优化方法论比较容易使用，很容易就可以获得系统出现性能问题的根本原因，从而进行高效率的性能优化工作。
UOWTBA优化方法论是本书介绍的核心工作方法之一，后面章节会引入更多的输入吞吐量压力描述，并且把UOWTBA优化工作方法全面作用在流程、资源和组件之中。