本节书摘来自华章计算机《Oracle数据库性能优化方法论和最佳实践》一书中的第1章，第1.3节，作者：柳遵梁 潘敏君 应以峰著，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.3 吞吐量和响应时间
吞吐量和响应时间是衡量Oracle业务系统的基本指标，也是业务系统性能的终极指标。如何选择恰当的指标单元来描述吞吐量和响应时间，并且熟练运用吞吐量和响应时间之间的关系是性能优化工作者最为重要的学习和实践。吞吐量和响应时间的关系曲线如此重要，以至于本书几乎所有的章节都是为了帮助大家更好地选择恰当的吞吐量指标，以及更好地理解吞吐量和响应时间的关系曲线。Oracle虽然从Oracle 10gR1就开始提供Time Based Analyze（TBA）性能优化分析方法论，但显然其并未认识到吞吐量和响应时间曲线的重要性，甚至到现在依然没有明确指出该曲线对性能优化具有的根本性理论指导作用，这也致使TBA分析方法论一直没有得到很好的利用。
1.3.1 吞吐量
吞吐量是一个简单的通用概念，不仅用于Oracle数据库，而且可用在任何提供服务的人和设备之上。关于吞吐量，笔者认为可以简单定义为如下形式：单位时间内完成的操作单元数量。这里的操作单元可以是任意粒度的指标，如transaction、executes、parse、logical reads、physical reads、user calls、latch gets、mutex gets等。
从性能优化的角度出发，吞吐量是一个输入指标，响应时间体现为在该吞吐量压力之下的输出指标。Oracle数据库有整体的吞吐量，listener、SGA、lgwr进程、CPU、I/O系统、内存和网络又有其各自的吞吐量。在一个Oracle业务系统中，在从客户机发布SQL语句到返回数据到客户机的漫长处理流程里，所涉及的每一个服务组件和资源（如CPU、内存等），其吞吐量都会有一定的限制。很显然，只有吞吐量的管道越来越粗，才有可能不会导致中间阻塞，才会使业务系统响应顺利流转。
对于交互式在线交易系统（OLTP）而言，其系统建设的根本目标总是被描述为在可接受的响应时间基础之上提供尽可能高的吞吐量，这也就成为任意OLTP系统性能优化的根本目标。如果一个性能优化者不理解这个OLTP系统特征，而简单强调尽可能快的响应时间，则可能会把系统优化带入歧途。
1.3.2 响应时间
响应时间同样是一个很简单的通用概念。笔者将其简单定义为：操作单元从开始到结束所消耗的时间。这里的操作单元与吞吐量定义中的含义完全一致。当这个操作单元完全是业务层面的最终感官响应时，就形成了端到端的响应时间，简单而言就是从操作者发起命令到返回响应结果所消耗的时间。
一般来说，响应时间被描述为平均响应时间，但性能优化者必须要考虑到在平均化之后所带来的平滑可能会导致结果不可观察。通常，平均化会导致以下两个问题。
部分业务或操作的问题会被平均化平滑。
部分时间的性能问题会被平均化平滑。
尤其是时间平滑问题会带来更多的现实挑战，因为相当多的业务性能问题并非是长时间的持续恶化，而是仅仅在某段时间之内出现。一个优秀的性能优化者必须可以正视平均化带来的指标观察问题。
大量的性能优化者通常会把焦点放在响应时间上，甚至Oracle的Time Based Analyze性能优化方法论也把更多的焦点放在了响应时间之上，但笔者认为这会把性能优化带入很大的误区。响应时间只是在特定吞吐量输入压力之下的输出响应指标，只是我们观察业务系统性能的一个最终反馈。尤其在OLTP系统中，简单地关注响应时间可能会带来灾难，而且有可能会采用消耗更多资源的方式来缩短响应时间，比如采用并行执行等，而这很可能是得不偿失的。
对于吞吐量和响应时间的优化，不同的业务系统其侧重点不同。对于OLTP系统，其业务系统的基本目标为：在可接受的响应时间范围之内吞吐量越大越好。换句话说，一笔交易在可接受的响应范围之内应该尽可能地降低资源消耗，因为资源是有限的。对于批处理和DSS系统，其业务系统的基本目标为：在有限的资源之内尽可能地缩短响应时间。换句话说，一笔交易应该尽可能地利用资源来加速业务处理。具体到性能优化，从上面可以很明确地看到，不同系统的性能优化方法和技术会有所不同。OLTP业务系统的基本方式为降低单位资源消耗，快速通过并发共享区域。批处理系统的基本方式为充分利用有效资源，独占式处理以加快响应。
1.3.3 吞吐量和响应时间关系曲线
对于性能优化者而言，吞吐量和响应时间的关系曲线图是最为重要的曲线图（见
图1-1），也是TBA性能优化分析方法的理论基础。在日常生活中，我们用成语“胸有成竹”来表示做事情有把握。对于性能优化者而言，“胸中有图”同样也可以保证性能优化会走在正确的道路之上，而不会被混乱的表象引入歧途。
从图1-1中可以发现以下几点。
在一定的吞吐量范围之内，响应时间基本保持稳定。用公式表示就是response time = service time。
在超过一定吞吐量之后，响应时间随着吞吐量的增加而增加，一直增加到响应时间不可接受为止。用公式表示为response time = service time + queue time。随着吞吐量的增加，service time将保持不变或小幅度波动，queue time则随着吞吐量的增加而不断增加。
在超过一定的吞吐量之后，响应时间进入突变点，随着吞吐量的增加，响应时间迅速增加，并很快会导致业务系统彻底不可用。
显而易见，降低吞吐量、queue time和service time是缩短响应时间的主要手段。
综上可得，一个性能优化者的根本目标就是在于延缓突变点的发生，使业务系统可以承受更多的吞吐量而保持在可接受的响应时间范围内。比如从图1-2所示的曲线中可以看出，从当前输入压力225的响应时间0.040优化为0.012左右，也许更好的描述方式为从突变点175调整为225。
1.3.4 医院挂号窗口的吞吐量和响应时间曲线
下面以一个医院挂号窗口的处理为例来感性描述吞吐量和响应时间的关系及优化方式。事实上，类似于医院挂号窗口的业务在现实世界中随处可见。
假设医院有4个挂号窗口，每个窗口的服务能力完全一样，每个窗口每分钟处理1个病人，每个病人的服务要求为最长等待时间不超过10分钟，这就意味着排队队伍不能超过10个病人。当维持有10个病人排队的时候，只需要开放1个窗口就可以满足业务需求，这个吞吐量是每分钟1个病人，响应时间（病人从入队到离队的时间）是10分钟。可以看到，在这种情况下每多开1个窗口，响应时间就会相应缩短。当有2个窗口提供服务时，每个队伍只有5个病人，响应时间为5分钟；当有3个窗口提供服务时，每个窗口只有3～4个病人，响应时间则为3～4分钟；当有4个窗口提供服务时，每个窗口只有2～3个病人，响应时间为2～3分钟。这时大家可以看到，无论是响应时间还是吞吐量都在快速上升。但是，随着每分钟排队病人的进一步增加，吞吐量将不再增加，而响应时间则会增加，当每个队伍增加为10个病人排队的时候，响应时间则相应变为10分钟，吞吐量为每分钟4个病人。当每个队伍的病人继续增加的时候，响应时间将线性增加，服务质量迅速恶化，吞吐量则基本不会上升。
下面看看在病人大规模增加而窗口规模保持不变的情况下应如何保证接收的服务质量。
首先简单分解挂号流程：
主流程：挂号职员接卡→获知挂号科室和医生→刷卡→选择科室→收钱→找钱→打印凭据→将卡和凭据还给病人。
副流程：填写病人信息→输入病人信息→制卡。
由上可以看到，这个处理流程的关键是要让挂号职员更加有效地利用其时间来处理信息，也就是尽可能地使其减少无效的等待时间。
服务改善方法之一：流程改善，同步操作异步化。
很明显，可以异步化的操作为：打印凭证和填写病人信息。事实上，打印凭证和填写病人信息也是最为耗时的操作。打印凭证是主流程的部分，至少达到总处理时间的1/3甚至以上，而填写病人信息则同样费时，假设也为总处理时间的1/3，需要填写病人信息的病人为总病人的10%，则这两部分异步化应该可以增加病人挂号吞吐量的35%甚至以上。
具体的异步化办法为：打印凭证时就可以让病人出队，在打印凭证的同时开始处理下一个病人的挂号。填写病人信息时可采用类似方法处理。这样一来，每个病人的服务时间并不会减少，甚至还会略微增加，但是每个病人的响应时间则缩短了35%以上，自然吞吐量也增加了35%以上。
服务改善方法之二：完全流程异步化以进一步增加吞吐量。
医院可以通过增加人手，把挂号处理流程变成流水化作业。假设是完全平均分担，即从1个人变成2个人，2个人变成4个人，则处理效率会相应地增加2倍，而响应时间则缩减为一半。为了支持更多的病人加入，可以不断增加人手，直到增加的人手不足以抵消流水线之间的交互为止。流水线化增加了单个病人的处理时间，但极大程度地增强了窗口处理能力，使其吞吐量大幅度增加，病人挂号的响应时间也大幅度降低。当然，流水线方式也会引入额外的成本，如流水线之间的沟通和交互时间等，而且窗口会存在接收和完成之间的冲突，当人手的增加不足以抵消协调和冲突成本时，吞吐量将达到极限。
服务改善方法之三：窗口人手并行化处理。
每个窗口安排2支队伍，而且安排2个职员提供服务，从而提供更高的吞吐量，缩短响应时间。如果需要进一步提高吞吐量，则可以在每个窗口安排更多的队伍和更多的服务人手。显然并行化方式会受到以下条件的限制：一是窗口之间的空间不足以安排更多的队伍（不过，虚拟排队可以部分解决这个问题）；二是由于单个窗口为很多队伍提供服务，所以会导致病人服务之间的冲突，当队伍的增加不足以抵消窗口冲突成本的时候，吞吐量将达到极限。
1.3.5 tpcc测试的吞吐量和响应时间曲线
图1-3～图1-5为笔者在笔记本电脑上利用tpcc测试工具hammerora得到的Oracle数据库的吞吐量和响应时间关系曲线，从图中可以看到，它们几乎与理论化的曲线完全一致，在到达突变点之后响应时间迅速增加。建议大家也进行相应的测试实践，以增强吞吐量和响应时间曲线的感性认识，从而更加深刻地把这个关系图映入脑海中，为你从事高级性能优化奠定良好的基础。
1.3.6 磁盘I/O系统吞吐量和响应时间曲线
本节将简单利用Oracle orion工具对磁盘进行测试，图1-6和图1-7是iops和响应时间之间的关系。从图中可以看出，随着iops的增加，单个I/O的响应时间也会随之增加。由于测试不够充分，并没有达到iops限制，因此从图1-6和图1-7可以看出以下几点：
随着iops的增加，响应时间会同时增加，但存在相对稳定期和快速增长期。
从混合I/O响应可以看出，随着输入压力的加大，iops达到限制之后吞吐量不会增加反而下跌。
随着iops达到系统限制，响应时间也会快速增加。
