1.3.2 响应时间

响应时间同样是一个很简单的通用概念。笔者将其简单定义为：操作单元从开始到结束所消耗的时间。这里的操作单元与吞吐量定义中的含义完全一致。当这个操作单元完全是业务层面的最终感官响应时，就形成了端到端的响应时间，简单而言就是从操作者发起命令到返回响应结果所消耗的时间。

一般来说，响应时间被描述为平均响应时间，但性能优化者必须要考虑到在平均化之后所带来的平滑可能会导致结果不可观察。通常，平均化会导致以下两个问题。

❑ 部分业务或操作的问题会被平均化平滑。

❑ 部分时间的性能问题会被平均化平滑。

尤其是时间平滑问题会带来更多的现实挑战，因为相当多的业务性能问题并非是长时间的持续恶化，而是仅仅在某段时间之内出现。一个优秀的性能优化者必须可以正视平均化带来的指标观察问题。

大量的性能优化者通常会把焦点放在响应时间上，甚至Oracle的Time Based Analyze性能优化方法论也把更多的焦点放在了响应时间之上，但笔者认为这会把性能优化带入很大的误区。响应时间只是在特定吞吐量输入压力之下的输出响应指标，只是我们观察业务系统性能的一个最终反馈。尤其在OLTP系统中，简单地关注响应时间可能会带来灾难，而且有可能会采用消耗更多资源的方式来缩短响应时间，比如采用并行执行等，而这很可能是得不偿失的。

对于吞吐量和响应时间的优化，不同的业务系统其侧重点不同。对于OLTP系统，其业务系统的基本目标为：在可接受的响应时间范围之内吞吐量越大越好。换句话说，一笔交易在可接受的响应范围之内应该尽可能地降低资源消耗，因为资源是有限的。对于批处理和DSS系统，其业务系统的基本目标为：在有限的资源之内尽可能地缩短响应时间。换句话说，一笔交易应该尽可能地利用资源来加速业务处理。具体到性能优化，从上面可以很明确地看到，不同系统的性能优化方法和技术会有所不同。OLTP业务系统的基本方式为降低单位资源消耗，快速通过并发共享区域。批处理系统的基本方式为充分利用有效资源，独占式处理以加快响应。