节选自图灵即将出版的《Troubleshooting Oracle Performance 》一书中文版，译者支付宝冯大辉等。红字是我做的批注和改动。总体翻译得很好，Fenng的辛苦没有白费。转自冯大辉的blog：http://www.dbanotes.net/database/top_howto_resolved_problem.html

简单而言，一个应用的目标是为使用它的业务提供便利。所以，对优化一个应用的性能进行优化的理由就是要最大化尽量增加这种便利。这并不意味着性能的最大化，而是要找到成本与性能之间的最佳平衡点。实际上，优化任务包括的努力总要从你期望获得的好处得到补偿。（这句话好像有点不通顺？）这意味着从商业（统一为业务？）的角度看，性能优化并不总是有意义的。

业务视角 vs. （vs.可以译为“与”）系统视角

优化一个应用的性能是为了给一个业务提供好处。所以当你着手处理接近(approaching)（【图灵动词规则】动词的翻译取决于施动者与受动者之间的关系，不要拘泥于字典中的常见义项。事实上，国内平庸字典给出的义项往往不全或者不准。approach本来就有To begin to deal with or work on之意）性能问题的时候，必须先理解业务问题和需求。，（注意译为中文后，要根据中文习惯重新断句）然后才跳入应用的细节。图1-2演示了所示为一个具有业务视角的人（一个用户）和一个具有系统视角的人（一个工程师）之间观察结果的典型差异不同。（不知道原文如何？）

图 1-2. 不同的观察者有不同的视角度

认识到两种视角之间的因果关系是重要的，虽然结果必须从业务视角来识别，其原因必须从系统视角来确定。所以，如果你不想去诊断不存在或不相干的问题（强迫调优失调症），理解从业务视角看问题就变得更重要 -- 即使这需要更多精细的工作。

把问题分类

对付性能问题的第一步，是要从业务视角确定问题，它们并为每个问题设定一个（如果不强调数量，中文里的“一个”往往是可以删除的）优先级和目标。如图1-3所示。

从业务视角来确定问题 > 设定每个问题的优先级 > 设定每个问题的优化目标

业务问题不能通过观察系统统计发现，而必须从业务视角来确定。如果代之以监控服务等级协议，很明显，可以从没有满足期望的操作来确定性能问题。（这句话好像有点读不懂？）否则，除了询问用户或者负责的人之外没有其他可能性。这种讨论将涉及一系列操作。例如：注册一个新用户，运行一个报告或加载一批可能很慢的数据。

你知道哪些操作是有问题的操作之后，就该给它他们排个优先级了。考虑类似这样的问题：如果我们只能处理5个问题，应该如何做呢？当然，最好是全部解决它们。但有时候时间或预算是有限的。此外，缺乏必要措施的情况下，不可能解决不同问题的相互冲突。要强调的是在设定优先级时，当前的性能可能是不相干的。例如，如果你处理一整套报告，不一定最慢的那个具有最高的优先级。可能最快的那个也是执行最频繁的那个，因此有可能具有最高优先级并需要首先优化。再说一次，是业务需求在驱动你。

对每项操作，你应当为优化设定一个可量度的目标。诸如"当创建用户按钮按下以后，处理时间最多2秒"。如果性能需求甚至服务等级协议可以得到，可能目标已经知道了。否则，再强调一次，必须考虑业务需求去确定目标。注意，没有目标就不知道何时停止不需要再继续研究一个更好的解决方案。换言之，优化可以是无止境的。 记住，努力永远要和获利取得平衡。

（总体上，这几段话比较枯燥，能否润色一下，显得面目更可亲一些？）

解决问题

诊断整个系统比诊断一个单独的组件要复杂得多。因此，任何可能的时候，你应当一次只解决一个问题，简单地从问题列表按照优先级从高到低的顺序解决。

对每个问题，如图1-4所示，必须回答3个问题：

• 时间花在哪里了？首先，你必须确定时间花在哪里了。例如，如果一个特定操作用时10秒，你必须找到这10秒里绝大部分花在哪个模块或组件。

• 时间是如何耗费（译成“是怎么花的”好像更顺，当然不改也可）的？一旦你知道时间花在哪里了，你必须找到时间是如何耗费的。例如，你发现应用用了4.2秒在CPU上，0.4秒做I/O操作，5.1秒等待另一个组件发出队列出队消息。
• 如何减少时间耗费？最后，才是找出怎样使操作更快的时候。要做到这个，重要的是聚焦到处理中最大时间消费的部分。例如，如果I/O操作占整个处理时间的4%，那么即使它很慢也没必要对他进行调整。

时间花在哪里了？ > 时间是如何耗费的？ > 如何减少时间耗费？ 

要注意由于副作用（原文是side effect吧，副作用中文的意思是不好的附加作用，如果你这里的附加作用是好的，就不要这样翻译，直接译为“附带作用”之类）的益处（这个益处读不太通），有时候修复一个特定问题的同时也会修复另一个问题。当然，相反的情况也会发生。，采取的措施可能引入新的问题。所以，很有必要认真考虑修复过程中可能引起的所有副作用。显然，所有改变在应用到生产环境前都要经过仔细测试。

发表于 @ 2009年05月05日　23:27:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:2009年度ACM编程竞赛结果揭晓 | 新一篇:25个最佳程序员漫画